Recent changes to this wiki:

update
diff --git a/blog/entry/hackerholler.mdwn b/blog/entry/hackerholler.mdwn
index 2b4063a..5f4c6ba 100644
--- a/blog/entry/hackerholler.mdwn
+++ b/blog/entry/hackerholler.mdwn
@@ -39,6 +39,4 @@ Update: That was too much to hope for as it turned out. But,
 this post did lead to some possibilities, which might let me afford
 the place. Stay tuned.
 
-<img src="https://hackerholler.branchable.com/woodstove.jpg">
-
 [[!meta author=Joey]]

update
diff --git a/blog/entry/hackerholler.mdwn b/blog/entry/hackerholler.mdwn
index 9e89a1c..2b4063a 100644
--- a/blog/entry/hackerholler.mdwn
+++ b/blog/entry/hackerholler.mdwn
@@ -35,11 +35,9 @@ a creek.
 Could we put all this together somehow? Might a handful of my friends
 be able to contribute somewhere in the range of $10 thousand to buy in?
 
-Interested? Want more details? Have ideas?  
-<b>Visit the <a href="https://hackerholler.branchable.com/">Hacker Holler website</a>
-and get in touch.</b>
-
-(Limited to folks I've met in person or spent a lot of time online with.)
+Update: That was too much to hope for as it turned out. But,
+this post did lead to some possibilities, which might let me afford
+the place. Stay tuned.
 
 <img src="https://hackerholler.branchable.com/woodstove.jpg">
 

scale
diff --git a/pics/brazil/2014/circle.jpg b/pics/brazil/2014/circle.jpg
index f95e45a..b966dec 100644
Binary files a/pics/brazil/2014/circle.jpg and b/pics/brazil/2014/circle.jpg differ

pic
diff --git a/pics/brazil/2014/circle.jpg b/pics/brazil/2014/circle.jpg
new file mode 100644
index 0000000..f95e45a
Binary files /dev/null and b/pics/brazil/2014/circle.jpg differ

wrinkle
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index 51340b0..c00b324 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -92,6 +92,13 @@ Asynchronous inputs are only used for sending signals, eg ctrl-c, not for
 sending keystrokes. This allows interruption of a running command at any
 time, without needing to catch up to its most recent output.
 
+It might seem like a good idea for a client to resend a rejected input,
+rebasing it on top of the new output. But, if a client did this, its user
+would have plausible deniability about what they intended that input to do.
+Perhaps they were not sending Y in response to "delete disk?", but to a
+previous question. So, inputs should not be resent. To prevent that,
+no message is sent to indicate when an input is rejected.
+
 Synchronous input interacts badly with terminal echo, because sending an
 input causes an echo output, and if that output has not been received by the
 time the next letter is input, the next input sent will be rejected. To

improved
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index 402018b..51340b0 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -32,29 +32,6 @@ being debugged.
 
 ### design
 
-#### interface
-
-Interface is as close to a ssh session as possible.
-
-It can be important to match terminal sizes, to make sure the developer
-is seeing same thing as the user. `debug-me` can assist with this by
-drawing a box and having the developer resize the terminal to enclose it,
-when the terminal sizes vary.
-
-It would be possible to have the user manually vet inputs and outputs,
-rather than generating a GPG signed proof of the developer's activity.
-But, this would significantly complicate things, by needing to display
-on the user's terminal what inputs and outputs remain to be vetted.
-The complication of implementing that does not seem worth it.
-Especially because manual vetting would introduce lag.
-
-The user can input stuff, just as well as the developer.
-
-It might be nice to have an integrated chat, but again this complicates
-the terminal handing significantly. User and developer can just as well
-chat on IRC anyway. Or run `screen` within `debug-me` and use one window
-to chat in.
-
 #### client-server
 
 This needs to be client-server, because a end user's machine is probably
@@ -69,40 +46,9 @@ gets an URL, which developers' clients can connect to in order to enter
 the session. Sharing that URL should be the only way for anyone to view
 the session (other than the person running the HTTP server).
 
-#### proof
-
-The developer activity proof takes the form of a chain of outputs and inputs.
-In other words, what the developer was shown, and what they did in response,
-and so on. Each input is GPG signed and includes SHA256 hashes of
-previous messages.
-
-A `debug-me` session starts by sending an initial output to the
-developer. Probably this is a shell prompt. (To prevent replay attacks
-of debug-me sessions it should also include a timestamp and/or a random token.)
-
-The developer enters a command, and their client hashes the previous output
-and includes that in a GPG signed message with the command. The ouput of
-the command then arrives, and is hashed and included in the next GPG signed
-input message, and so on.
-
-Note that an input is only accepted if it includes the hashes of
-the previous input (if any) and all outputs since the previous input.
-
-A race is possible, where the developer's client sends an input before
-receiving a new output, and so their input is rejected. Their client can
-deal with this by re-sending the input, including the hash of the new
-output. Problem: If new output is constantly arriving, an input of eg
-ctrl-c to interrupt it may never be accepted. Perhaps an input should
-instead be accepted as long as it includes a hash of any of a recent
-output? Would that be as secure? It may give a developer plausible
-deniability, that they did not mean to send "y" in response to "format
-disk?" but in response to the previous output. Even resending inputs
-on race can give some plausible deniability about what the developer
-saw when they made the input.
-
 Multiple clients can be connected, and all send inputs. The user's
-client will only accept inputs GPG signed with keys that the user has
-granted access.
+client will only accept inputs GPG signed with keys that the user
+has granted access.
 
 When a new client connects, the whole session is sent to it, so it
 gets caught up and can start adding inputs to the chain.
@@ -112,11 +58,80 @@ to run `debug-me` on another computer, to record the developer activity proof
 there. This way a very Evil developer can't delete the user's only copy of
 the proof of their Evil.
 
-The server can also record the session, but this doesn't help if the
+The server can also record the session. This doesn't help if the
 developer is running the server. But if there are multiple servers
 run by different people, the user's client could send the session to
 several of them to get it recorded.
 
+#### proof
+
+The developer activity proof takes the form of a chain of outputs and inputs.
+In other words, what the developer was shown, and what they did in response,
+and so on. Each input is GPG signed and includes the SHA256 hash of a
+previous output or input.
+
+A `debug-me` session starts by generating an initial output.
+Probably this is a shell prompt. (To prevent replay attacks
+of debug-me sessions it should also include a timestamp and/or a random token.)
+
+The developer enters a command, and their client hashes the last seen
+output and includes that in a GPG signed message with the command. The
+ouput of the command then arrives, and is hashed and included in the next
+GPG signed input message, and so on.
+
+There are two kinds of inputs: Synchronous and asynchronous.
+
+A synchronous input must include the hash of the output that it was made
+in response to, and will only be accepted by the user's client when that
+output is the last one that was sent. This way it's always clear what
+the state of the debug-me session was when the developer saw the output
+and entered a given input.
+
+An asynchronous input must include the hash of the previous input.
+Asynchronous inputs are only used for sending signals, eg ctrl-c, not for
+sending keystrokes. This allows interruption of a running command at any
+time, without needing to catch up to its most recent output.
+
+Synchronous input interacts badly with terminal echo, because sending an
+input causes an echo output, and if that output has not been received by the
+time the next letter is input, the next input sent will be rejected. To
+deal with this, an input can include an echo block. If the echo block has
+the same content as the sum of outputs sent since the output that the input
+is in response to, then the input will be accepted.
+
+For example:
+
+	1. output "prompt>"
+	2. input "t" (previous: 1)
+	3. output "t" (previous: 2)
+	4. input "o" (previous: 1, echo: "t") -- valid because "t" = 3
+	5. output "o" (previous: 4)
+	6. input "p" (1, echo: "to") -- valid because "to" = 3+5
+	7. output: "p" (previous: 6)
+
+#### interface
+
+Interface is as close to a ssh session as possible.
+
+The user can input stuff, just as well as the developer.
+
+It can be important to match terminal sizes, to make sure the developer
+is seeing same thing as the user. `debug-me` can assist with this by
+drawing a box and having the developer resize the terminal to enclose it,
+when the terminal sizes vary.
+
+It would be possible to have the user manually vet inputs and outputs,
+rather than generating a GPG signed proof of the developer's activity.
+But, this would significantly complicate things, by needing to display
+on the user's terminal what inputs and outputs remain to be vetted.
+The complication of implementing that does not seem worth it.
+Especially because manual vetting would introduce lag.
+
+It might be nice to have an integrated chat, but again this complicates
+the terminal handing significantly. User and developer can just as well
+chat on IRC anyway. Or run `screen` within `debug-me` and use one window
+to chat in.
+
 #### installation
 
 For `debug-me` to be most useful, it will need to be included in major

tweaks
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index 19a1c05..402018b 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -77,10 +77,13 @@ and so on. Each input is GPG signed and includes SHA256 hashes of
 previous messages.
 
 A `debug-me` session starts by sending an initial output to the
-developer. Probably this is a shell prompt. The developer enters a command,
-and their client hashes the previous output and includes that in a GPG signed
-message with the command. The ouput of the command then arrives, and is
-hashed and included in the next GPG signed input message, and so on.
+developer. Probably this is a shell prompt. (To prevent replay attacks
+of debug-me sessions it should also include a timestamp and/or a random token.)
+
+The developer enters a command, and their client hashes the previous output
+and includes that in a GPG signed message with the command. The ouput of
+the command then arrives, and is hashed and included in the next GPG signed
+input message, and so on.
 
 Note that an input is only accepted if it includes the hashes of
 the previous input (if any) and all outputs since the previous input.
@@ -88,7 +91,14 @@ the previous input (if any) and all outputs since the previous input.
 A race is possible, where the developer's client sends an input before
 receiving a new output, and so their input is rejected. Their client can
 deal with this by re-sending the input, including the hash of the new
-output.
+output. Problem: If new output is constantly arriving, an input of eg
+ctrl-c to interrupt it may never be accepted. Perhaps an input should
+instead be accepted as long as it includes a hash of any of a recent
+output? Would that be as secure? It may give a developer plausible
+deniability, that they did not mean to send "y" in response to "format
+disk?" but in response to the previous output. Even resending inputs
+on race can give some plausible deniability about what the developer
+saw when they made the input.
 
 Multiple clients can be connected, and all send inputs. The user's
 client will only accept inputs GPG signed with keys that the user has
@@ -99,8 +109,13 @@ gets caught up and can start adding inputs to the chain.
 
 Other clients can connect and only record the session. This allows a user
 to run `debug-me` on another computer, to record the developer activity proof
-there. This way a very Evil developer can't delete the user's
-only copy of the proof of their Evil.
+there. This way a very Evil developer can't delete the user's only copy of
+the proof of their Evil.
+
+The server can also record the session, but this doesn't help if the
+developer is running the server. But if there are multiple servers
+run by different people, the user's client could send the session to
+several of them to get it recorded.
 
 #### installation
 

clarif
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index 5789259..19a1c05 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -73,8 +73,8 @@ the session (other than the person running the HTTP server).
 
 The developer activity proof takes the form of a chain of outputs and inputs.
 In other words, what the developer was shown, and what they did in response,
-and so on. Each input is GPG signed and includes the SHA256 hashes of one or
-more outputs that came before it.
+and so on. Each input is GPG signed and includes SHA256 hashes of
+previous messages.
 
 A `debug-me` session starts by sending an initial output to the
 developer. Probably this is a shell prompt. The developer enters a command,

clarif
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index ca2f900..5789259 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -82,17 +82,31 @@ and their client hashes the previous output and includes that in a GPG signed
 message with the command. The ouput of the command then arrives, and is
 hashed and included in the next GPG signed input message, and so on.
 
-Note that an input is only accepted if it includes the hash of the
-most recent output. A race is possible, where the developer's client sends
-an input before receiving a new output, and so their input is rejected.
-Their client can deal with this by re-sending the input, including the hash of
-the new output.
+Note that an input is only accepted if it includes the hashes of
+the previous input (if any) and all outputs since the previous input.
+
+A race is possible, where the developer's client sends an input before
+receiving a new output, and so their input is rejected. Their client can
+deal with this by re-sending the input, including the hash of the new
+output.
 
 Multiple clients can be connected, and all send inputs. The user's
 client will only accept inputs GPG signed with keys that the user has
 granted access.
 
-Other clients can connect and only record all the outputs. This allows a user
+When a new client connects, the whole session is sent to it, so it
+gets caught up and can start adding inputs to the chain.
+
+Other clients can connect and only record the session. This allows a user
 to run `debug-me` on another computer, to record the developer activity proof
 there. This way a very Evil developer can't delete the user's
 only copy of the proof of their Evil.
+
+#### installation
+
+For `debug-me` to be most useful, it will need to be included in major
+distributions. It should also be as easy as possible to install manually.
+
+It may be helpful for programs to bundle `debug-me`, at least
+until the standalone `debug-me` is widely available. For example, I can
+imagine including it in the standalone git-annex bundles.

foo
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index c58c9d4..ca2f900 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -10,14 +10,6 @@ A not yet implemented idea from [[blog/entry/Re:_Debugging_over_email]]:
 > the user pastes some output of running some commands and I mentally skip
 > right over an important part of it. Because I didn't think to run one of
 > the commands myself.
-> 
-> I wonder if it would be helpful to have a kind of ssh equivilant, where
-> all commands get vetted by the remote user before being run on their
-> system. (And the user can also see command output before it gets
-> sent back, to NACK sending of personal information.)
-> So, it looks and feels a lot like you're in a mosh session to the user's
-> computer (which need not have a public IP or have an open ssh port at all),
-> although one with a lot of lag and where `rm -rf /` doesn't go through.
 
 `debug-me` lets a developer access your shell remotely, to debug a problem,
 avoiding a tedious back-and-forth by email. When you start `debug-me`, it

update
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index 0031f4a..c58c9d4 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -1,5 +1,16 @@
 A not yet implemented idea from [[blog/entry/Re:_Debugging_over_email]]:
 
+> I've noticed that once I am in a position to run some commands in the
+> environment that has the problem, it seems to be much easier to solve
+> it than when I'm trying to get the user to debug it remotely. This must
+> be partly psychological?
+> 
+> Partly, I think that the feeling of being at a remove from the system,
+> makes it harder to think of what to do. And then there are the times where
+> the user pastes some output of running some commands and I mentally skip
+> right over an important part of it. Because I didn't think to run one of
+> the commands myself.
+> 
 > I wonder if it would be helpful to have a kind of ssh equivilant, where
 > all commands get vetted by the remote user before being run on their
 > system. (And the user can also see command output before it gets

not yet implemented
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index d0252a3..0031f4a 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -1,4 +1,4 @@
-Idea from [[blog/entry/Re:_Debugging_over_email]]:
+A not yet implemented idea from [[blog/entry/Re:_Debugging_over_email]]:
 
 > I wonder if it would be helpful to have a kind of ssh equivilant, where
 > all commands get vetted by the remote user before being run on their

idea
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
new file mode 100644
index 0000000..d0252a3
--- /dev/null
+++ b/code/debug-me.mdwn
@@ -0,0 +1,95 @@
+Idea from [[blog/entry/Re:_Debugging_over_email]]:
+
+> I wonder if it would be helpful to have a kind of ssh equivilant, where
+> all commands get vetted by the remote user before being run on their
+> system. (And the user can also see command output before it gets
+> sent back, to NACK sending of personal information.)
+> So, it looks and feels a lot like you're in a mosh session to the user's
+> computer (which need not have a public IP or have an open ssh port at all),
+> although one with a lot of lag and where `rm -rf /` doesn't go through.
+
+`debug-me` lets a developer access your shell remotely, to debug a problem,
+avoiding a tedious back-and-forth by email. When you start `debug-me`, it
+starts a shell, and generates an URL which you can give to the developer
+(or developers) to connect them to the session.
+
+It's not normally a good idea to let someone run commands in a shell on
+your computer. To make this as safe as possible, `debug-me` uses the
+GPG web of trust. Everything the developer sends to `debug-me` is signed
+with their GPG key, in a way that produces a GPG signed proof of what the
+developer saw, and what they did in the `debug-me` session.
+If the developer does something Evil, you have the neccessary proof
+to adjust their reputation.
+
+As well as checking the GPG web of trust, `debug-me` can clone the git
+repository of the program that it's being used to debug, and check for GPG
+signed git tags and commits made using the developer's key. This helps you
+tell if the person connecting to `debug-me` is a developer of the program
+being debugged.
+
+### design
+
+#### interface
+
+Interface is as close to a ssh session as possible.
+
+It can be important to match terminal sizes, to make sure the developer
+is seeing same thing as the user. `debug-me` can assist with this by
+drawing a box and having the developer resize the terminal to enclose it,
+when the terminal sizes vary.
+
+It would be possible to have the user manually vet inputs and outputs,
+rather than generating a GPG signed proof of the developer's activity.
+But, this would significantly complicate things, by needing to display
+on the user's terminal what inputs and outputs remain to be vetted.
+The complication of implementing that does not seem worth it.
+Especially because manual vetting would introduce lag.
+
+The user can input stuff, just as well as the developer.
+
+It might be nice to have an integrated chat, but again this complicates
+the terminal handing significantly. User and developer can just as well
+chat on IRC anyway. Or run `screen` within `debug-me` and use one window
+to chat in.
+
+#### client-server
+
+This needs to be client-server, because a end user's machine is probably
+buried behind NAT. 
+
+It should use HTTPS, because of stupid firewalls. Will need to
+use some form of long polling to get multiple messages promptly in
+both directions.
+
+The user's client picks which server to use, connects, and
+gets an URL, which developers' clients can connect to in order to enter
+the session. Sharing that URL should be the only way for anyone to view
+the session (other than the person running the HTTP server).
+
+#### proof
+
+The developer activity proof takes the form of a chain of outputs and inputs.
+In other words, what the developer was shown, and what they did in response,
+and so on. Each input is GPG signed and includes the SHA256 hashes of one or
+more outputs that came before it.
+
+A `debug-me` session starts by sending an initial output to the
+developer. Probably this is a shell prompt. The developer enters a command,
+and their client hashes the previous output and includes that in a GPG signed
+message with the command. The ouput of the command then arrives, and is
+hashed and included in the next GPG signed input message, and so on.
+
+Note that an input is only accepted if it includes the hash of the
+most recent output. A race is possible, where the developer's client sends
+an input before receiving a new output, and so their input is rejected.
+Their client can deal with this by re-sending the input, including the hash of
+the new output.
+
+Multiple clients can be connected, and all send inputs. The user's
+client will only accept inputs GPG signed with keys that the user has
+granted access.
+
+Other clients can connect and only record all the outputs. This allows a user
+to run `debug-me` on another computer, to record the developer activity proof
+there. This way a very Evil developer can't delete the user's
+only copy of the proof of their Evil.

Added a comment: NixOS
diff --git a/blog/entry/twenty_years_of_free_software_--_part_12_propellor/comment_1_f395278d850d9c8409a1c52d52755311._comment b/blog/entry/twenty_years_of_free_software_--_part_12_propellor/comment_1_f395278d850d9c8409a1c52d52755311._comment
new file mode 100644
index 0000000..24004e7
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_12_propellor/comment_1_f395278d850d9c8409a1c52d52755311._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mr@e1f11bbd433e35f4e30d1cacaf1585fe2573f933"
+ nickname="mr"
+ subject="NixOS"
+ date="2016-07-20T10:54:28Z"
+ content="""
+How is propellor similar/different to NixOS?
+"""]]

update
diff --git a/blog/entry/Re:_Debugging_over_email.mdwn b/blog/entry/Re:_Debugging_over_email.mdwn
index f6a8d16..3f680a6 100644
--- a/blog/entry/Re:_Debugging_over_email.mdwn
+++ b/blog/entry/Re:_Debugging_over_email.mdwn
@@ -26,10 +26,11 @@ thinking much and see if you can reproduce the bug. So I tend to look at
 such bug reports first, and solve them more quickly, which tends towards
 a virtuous cycle.
 
-I've noticed that reams of debugging output, logs, test suite failures,
-reproduction recipes etc can be useful once I'm well into tracking a
-problem down. But during triage, they make it harder to understand what
-the problem actually is. Information overload.
+I've noticed that reams of debugging output, logs, test suite failures, etc
+can be useful once I'm well into tracking a problem down. But during
+triage, they make it harder to understand what the problem actually is.
+Information overload. Being able to reproduce the problem myself is far
+more valuable than this stuff.
 
 I've noticed that once I am in a position to run some commands in the
 environment that has the problem, it seems to be much easier to solve

blog update
diff --git a/blog/entry/Re:_Debugging_over_email.mdwn b/blog/entry/Re:_Debugging_over_email.mdwn
new file mode 100644
index 0000000..f6a8d16
--- /dev/null
+++ b/blog/entry/Re:_Debugging_over_email.mdwn
@@ -0,0 +1,51 @@
+[Lars wrote about the remote debugging problem.](http://blog.liw.fi/posts/debugging-over-email/)
+
+> I write free software and I have some users. My primary support channels are
+> over email and IRC, which means I do not have direct access to the system
+> where my software runs. When one of my users has a problem, we go through one
+> or more cycles of them reporting what they see and me asking them for more
+> information, or asking them to try this thing or that thing and report
+> results. This can be quite frustrating.
+> 
+> I want, nay, need to improve this.
+
+This is also something I've thought about on and off, that affects me
+most every day.
+
+I've found that building the test suite into the program, such that
+users can run it at any time, is a great way to smoke out problems. If a
+user thinks they have problem A but the test suite explodes, or
+also turns up problems B C D, then I have much more than the user's
+problem report to go on. `git annex test` is a good example of this.
+
+Asking users to provide a recipe to reproduce the bug is very helpful;
+I do it in the git-annex bug report template, and while not all users
+do, and users often provide a reproducion recipe that doesn't quite
+work, it's great in triage to be able to try a set of steps without
+thinking much and see if you can reproduce the bug. So I tend to look at
+such bug reports first, and solve them more quickly, which tends towards
+a virtuous cycle.
+
+I've noticed that reams of debugging output, logs, test suite failures,
+reproduction recipes etc can be useful once I'm well into tracking a
+problem down. But during triage, they make it harder to understand what
+the problem actually is. Information overload.
+
+I've noticed that once I am in a position to run some commands in the
+environment that has the problem, it seems to be much easier to solve
+it than when I'm trying to get the user to debug it remotely. This must
+be partly psychological?
+
+Partly, I think that the feeling of being at a remove from the system,
+makes it harder to think of what to do. And then there are the times where
+the user pastes some output of running some commands and I mentally skip
+right over an important part of it. Because I didn't think to run one of
+the commands myself.
+
+I wonder if it would be helpful to have a kind of ssh equivilant, where
+all commands get vetted by the remote user before being run on their
+system. (And the user can also see command output before it gets
+sent back, to NACK sending of personal information.)
+So, it looks and feels a lot like you're in a mosh session to the user's
+computer (which need not have a public IP or have an open ssh port at all),
+although one with a lot of lag and where `rm -rf /` doesn't go through.

Added a comment: This library would be useful for...
diff --git a/blog/entry/concurrent_output_library/comment_4_8284c008fafec8c9f4deaf9362c053c4._comment b/blog/entry/concurrent_output_library/comment_4_8284c008fafec8c9f4deaf9362c053c4._comment
new file mode 100644
index 0000000..4ca2972
--- /dev/null
+++ b/blog/entry/concurrent_output_library/comment_4_8284c008fafec8c9f4deaf9362c053c4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="dave@2ab82f485adf7e2ce787066e35f5f9789bff430b"
+ nickname="dave"
+ subject="This library would be useful for..."
+ date="2016-07-18T16:31:47Z"
+ content="""
+This library would be useful in a Haskell clone of this project: https://blog.ghaiklor.com/ascii-presentations-in-terminal-are-real-aa3bbe3c215
+"""]]

2016 ocracoke trip
diff --git a/ocracode.mdwn b/ocracode.mdwn
index 03d2236..d15d2cb 100644
--- a/ocracode.mdwn
+++ b/ocracode.mdwn
@@ -116,3 +116,4 @@ describe your camping trip to Ocracoke.
 * [[2011|blog/entry/summer_trips_wrapup]]
 * [[2014|blog/entry/laptop_death]]
 * [[2015|ocracode/2015]]
+* [[2015|ocracode/2016]]
diff --git a/ocracode/2016.mdwn b/ocracode/2016.mdwn
new file mode 100644
index 0000000..6cd33c7
--- /dev/null
+++ b/ocracode/2016.mdwn
@@ -0,0 +1,2 @@
+OBX1.1 P8 L6 SA11s--A3d- U1(did not move whole camp to dune site)  
+T1f0b0 R2 Bb+m+n++ F+++u++ SC--s+g10 H+f0i4 V-s-m0 E-r--

new url
diff --git a/grep.mdwn b/grep.mdwn
index f13c25e..e73e432 100644
--- a/grep.mdwn
+++ b/grep.mdwn
@@ -8,6 +8,5 @@ on the net.
 List of feeds:
 
 * [[!aggregate expirecount=25 name="music" feedurl="http://libre.fm/rdf.php?fmt=rss&page=%2Fuser%2Fjoeyhess%2Frecent-tracks" url="http://libre.fm/user/joeyhess"]]
-* [[!aggregate expirecount=25 name="identi.ca posts" feedurl="http://tmp.kitenet.net/pump.atom" url="http://identi.ca/joeyh"]]
-* [[!aggregate expirecount=25 name="twitter grep" feedurl="http://tmp.kitenet.net/twittergrep.rss" url="https://twitter.com/search/realtime?q=olduse+OR+git-annex+OR+debhelper+OR+etckeeper+OR+ikiwiki+-ashley_ikiwiki"]]
+* [[!aggregate expirecount=25 name="identi.ca posts" feedurl="http://tmp.joeyh.name/pump.atom" url="http://identi.ca/joeyh"]]
 * [[!aggregate expirecount=25 name="books" feedurl="http://www.goodreads.com/review/list_rss/2159448?key=afd7e8432b3f9e33edab442a7c94e95849af4527&shelf=currently-reading" url="http://www.goodreads.com/user/show/2159448"]]

post
diff --git a/blog/entry/twenty_years_of_free_software_--_part_13_past_and_future.mdwn b/blog/entry/twenty_years_of_free_software_--_part_13_past_and_future.mdwn
new file mode 100644
index 0000000..c411b1f
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_13_past_and_future.mdwn
@@ -0,0 +1,30 @@
+This series has focused on new projects. I could have said more about
+significant work that didn't involve starting new projects. A big example was
+when I added `dh` to debhelper, which led to changes in a large
+percentage of `debian/rules` files. And I've contributed to many other free
+software projects.
+
+I guess I've focused on new projects becuase it's easier to remember things
+I've started myself. And because a new project is more wide open, with more
+scope for interesting ideas, especially when it's free software being
+created just because I want to, with no expectations of success.
+
+But starting lots of your own projects also makes you responsible for
+maintaining a lot of stuff. Ten years ago I had dozens of projects that I'd
+started and was still maintaining. Over time I started pulling away from
+Debian, with active projects increasingly not connected with it. By the end,
+I'd left and stopped working on the old projects. Nearly everything from my
+first decade in free software was passed on to new maintainers. It's good
+to get out from under old projects and concentrate on new things.
+
+I saved propellor for last in this series, because I think it may point
+toward the future of my software. While git-annex was the project that
+taught me Haskell, propellor's design is much more deeply influenced by the
+Haskell viewpoint.
+
+Absorbing that viewpoint has itself been a big undertaking for me this decade.
+It's like I was coasting along feeling at the top of my game
+and *wham* got hit by the type theory bus. And now I see that I was stuck
+in a rut before, and begin to get a feeling of many new possibilities.
+
+That's a good feeling to have, twenty years in.

fix typo in blog post
diff --git a/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn b/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn
index b32193f..399a682 100644
--- a/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn
+++ b/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn
@@ -18,7 +18,7 @@ the motivation for it like this, in a proposal for a Linux.Conf.Au talk:
 
 The real origin story though, is that I wanted to finally start using
 configuration management, but the tools for it all seemed very complicated
-and built on shakey foundations (like piles of yaml), and it seemed it
+and built on shaky foundations (like piles of yaml), and it seemed it
 would be easier to write my own than deal with that. Meanwhile, I had
 Haskell burning a hole in my pocket, ready to be used in a second large
 project after git-annex.

post
diff --git a/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn b/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn
new file mode 100644
index 0000000..b32193f
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn
@@ -0,0 +1,44 @@
+[[code/Propellor]] is my second big Haskell program. I recently described
+the motivation for it like this, in a proposal for a Linux.Conf.Au talk:
+
+> The configuration of Linux hosts has become increasingly declarative,
+> managed by tools like puppet and ansible, or by the composition of
+> containers. But if a server is a collection of declarative properties, how
+> do you make sure that changes to that configuration make sense? You can
+> test them, but eventually it's 3 AM and you have an emergency fix that
+> needs to go live immediately.
+> 
+> Data types to the rescue! While data types are usually used to prevent eg,
+> combining an Int and a Bool, they can be used at a much more abstract
+> level, for example to prevent combining a property that needs a Debian
+> system with a property that needs a Red Hat system.
+> 
+> Propellor leverages Haskell's type system to prove the consistency of the
+> properties it will apply to a host.
+
+The real origin story though, is that I wanted to finally start using
+configuration management, but the tools for it all seemed very complicated
+and built on shakey foundations (like piles of yaml), and it seemed it
+would be easier to write my own than deal with that. Meanwhile, I had
+Haskell burning a hole in my pocket, ready to be used in a second large
+project after git-annex.
+
+Propellor has averaged around 2.5 contributions per month from users since
+it got started, but increasing numbers recently. That's despite having many
+fewer users than git-annex, which remember gets
+[[perhaps 1 patch per month|twenty_years_of_free_software_--_part_7_git-annex]].
+
+Of course, I've "cheated" by making sure that propellor's users know Haskell,
+or are willing to learn some. And, propellor is very compositional; adding
+a new property to it is not likely to be complicated by any of the existing
+code. So it's easy to extend, if you're able to use it.
+
+At this point propellor has a small community of regular contributors, and I
+spend some pleasant weekend afternoons reviewing and merging their work.
+
+Much of my best work on propellor has involved keeping the behavior of the
+program the same while making its types better, to prevent mistakes.
+Propellor's core data types have evolved much more than in any program I
+worked on before. That's exciting!
+
+Next: [[twenty_years_of_free_software_--_part_13_past_and_future]]

post
diff --git a/blog/entry/twenty_years_of_free_software_--_part_11_concurrent-output.mdwn b/blog/entry/twenty_years_of_free_software_--_part_11_concurrent-output.mdwn
new file mode 100644
index 0000000..43cbbd1
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_11_concurrent-output.mdwn
@@ -0,0 +1,13 @@
+[[code/concurrent-output]] is a more meaty Haskell library than the ones
+I've covered so far. Its interface is simple, but there's a lot of
+complexity under the hood. Things like optimised console updates,
+ANSI escape sequence parsing, and transparent paging of buffers to disk.
+
+It developed out of needing to display multiple progress bars on the
+console in git-annex, and also turned out to be useful in propellor.
+And since it solves a general problem, other haskell programs are moving
+toward using it, like
+[shake](https://asciinema.org/a/43357) and
+[stack](https://github.com/mboes/stack/commit/f1c6711c733885738a323c7392e1d912921bc881).
+
+Next: [[twenty_years_of_free_software_--_part_12_propellor]]

post
diff --git a/blog/entry/twenty_years_of_free_software_--_part_10_shell-monad.mdwn b/blog/entry/twenty_years_of_free_software_--_part_10_shell-monad.mdwn
new file mode 100644
index 0000000..ff91576
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_10_shell-monad.mdwn
@@ -0,0 +1,26 @@
+[[code/shell-monad]] is a small project, done over a couple days and 
+not needing many changes since, but I'm covering it separately because it
+was a bit of a milestone for me.
+
+As I learned Haskell, I noticed that the libraries were excellent and did
+things to guide their users that libraries in other languages don't do.
+Starting with using types and EDSLs and carefully constrained interfaces,
+but going well beyond that, as far as applying category theory.
+Using these libraries push you toward good solutions.
+
+shell-monad was a first attempt at building such a library. The shell
+script it generates should always be syntactically valid, and never forgets
+to quote a shell variable. That's only the basics. It goes further by
+making it impossible to typo the name of a shell variable or shell
+function. And it uses phantom types so that the Haskell type checker can
+check the types of shell variables and functions match up.
+
+So I think shell-monad is pretty neat, and I certianly learned a lot
+about writing Haskell libraries making it. Including how much I still have
+to learn!
+
+I have not used shell-monad much, but keep meaning to make propellor
+and git-annex use it for some of their shell script needs. And ponder
+porting [[code/etckeeper]] to generate its shell scripts using it.
+
+Next: [[twenty_years_of_free_software_--_part_11_concurrent-output]]

fix links
diff --git a/blog/entry/twenty_years_of_free_software_--_part_9_small_projects.mdwn b/blog/entry/twenty_years_of_free_software_--_part_9_small_projects.mdwn
index 90a2f54..c2a89ba 100644
--- a/blog/entry/twenty_years_of_free_software_--_part_9_small_projects.mdwn
+++ b/blog/entry/twenty_years_of_free_software_--_part_9_small_projects.mdwn
@@ -1,14 +1,14 @@
-My dad sometimes asks when I'll finish git-annex. The answer is "I don't
+ey dad sometimes asks when I'll finish git-annex. The answer is "I don't
 know" because software like that doesn't have a defined end point; it grows
 and changes in response to how people use it and how the wider ecosystem
 develops.
 
 But other software has a well-defined end point and can be finished.
 Some of my smaller projects that are more or less done include
-[[code/myrepos]], [[code/electrum-mnemonic]], [[code/brainfuck-monad]],
+[[code/electrum-mnemonic]], [[code/brainfuck-monad]],
 [[code/scroll]], 
-[yesod-lucid](http://hackage.haskell.org/yesod-lucid)
-[haskell-mountpoints](http://hackage.haskell.org/haskell-mountpoints).
+[yesod-lucid](http://hackage.haskell.org/package/yesod-lucid)
+[haskell-mountpoints](http://hackage.haskell.org/package/haskell-mountpoints).
 
 Studies of free software projects have found that the average free software
 project was written entirely by one developer, is not very large, and is
diff --git a/blog/entry/twenty_years_of_free_software_--_part_9_small_projects/comment_2_974a3df54ac6be6a64a36001eb630ad3._comment b/blog/entry/twenty_years_of_free_software_--_part_9_small_projects/comment_2_974a3df54ac6be6a64a36001eb630ad3._comment
new file mode 100644
index 0000000..ad4b675
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_9_small_projects/comment_2_974a3df54ac6be6a64a36001eb630ad3._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-07-07T05:20:13Z"
+ content="""
+Fixed that.
+"""]]

Added a comment: Bad HTML links
diff --git a/blog/entry/twenty_years_of_free_software_--_part_9_small_projects/comment_1_0f08b551242c9f9473bf5a8ab9e6d135._comment b/blog/entry/twenty_years_of_free_software_--_part_9_small_projects/comment_1_0f08b551242c9f9473bf5a8ab9e6d135._comment
new file mode 100644
index 0000000..9002fd8
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_9_small_projects/comment_1_0f08b551242c9f9473bf5a8ab9e6d135._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="rsmith@9a1504b59ae3e2419ba4d8e8695f28ad8e9639cd"
+ nickname="rsmith"
+ subject="Bad HTML links"
+ date="2016-07-07T01:00:04Z"
+ content="""
+The links for yesod-lucid and mountpoint are incorrect, and myrepos requires a signin?
+"""]]

post
diff --git a/blog/entry/twenty_years_of_free_software_--_part_9_small_projects.mdwn b/blog/entry/twenty_years_of_free_software_--_part_9_small_projects.mdwn
new file mode 100644
index 0000000..90a2f54
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_9_small_projects.mdwn
@@ -0,0 +1,21 @@
+My dad sometimes asks when I'll finish git-annex. The answer is "I don't
+know" because software like that doesn't have a defined end point; it grows
+and changes in response to how people use it and how the wider ecosystem
+develops.
+
+But other software has a well-defined end point and can be finished.
+Some of my smaller projects that are more or less done include
+[[code/myrepos]], [[code/electrum-mnemonic]], [[code/brainfuck-monad]],
+[[code/scroll]], 
+[yesod-lucid](http://hackage.haskell.org/yesod-lucid)
+[haskell-mountpoints](http://hackage.haskell.org/haskell-mountpoints).
+
+Studies of free software projects have found that the average free software
+project was written entirely by one developer, is not very large, and is
+not being updated. That's often taken to mean it's a failed or dead
+project. But all the projects above look that way, and are not failures, or
+dead.
+
+It's good to actually finish some software once in a while!
+
+Next: [[twenty_years_of_free_software_--_part_10_shell-monad]]

add
diff --git a/blog/entry/twenty_years_of_free_software_--_part_8_github-backup.mdwn b/blog/entry/twenty_years_of_free_software_--_part_8_github-backup.mdwn
new file mode 100644
index 0000000..5b35b8e
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_8_github-backup.mdwn
@@ -0,0 +1,20 @@
+[[code/github-backup]] is an attempt to take something I don't like --
+github's centralization of what should be a decentralized techology -- and
+find a constrictive way to make it at least meet my baseline requirements
+for centralized systems. Namely that when they go away, I don't lose data.
+
+So, it was written partly with my [[ArchiveTeam|I_Am_ArchiveTeam]] hat on.
+
+A recent bug filed on it, 
+[Backup fails for repositories unavailable due to DMCA takedown](https://github.com/joeyh/github-backup/issues/58)
+made me happy, because it shows github-backup behaving more or less as
+intended, although perhaps not in the optimal way.
+
+By the way, this is the only one of my projects that uses github for issue
+tracking. Intentionally ironically.
+
+It was my second real Haskell program (after git-annex) 
+and so also served as a good exercise in applying what
+I'd learned about writing Haskell up to that point.
+
+Next: [[twenty_years_of_free_software_--_part_9_small_projects]]

post
diff --git a/blog/entry/twenty_years_of_free_software_--_part_7_git-annex.mdwn b/blog/entry/twenty_years_of_free_software_--_part_7_git-annex.mdwn
new file mode 100644
index 0000000..19cdfaf
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_7_git-annex.mdwn
@@ -0,0 +1,50 @@
+My first Haskell program, and the only software I've written that
+was inspired by living in a [[particular place|hackerholler]],
+[[code/git-annex]] has received the lion's share of my time for five
+years.
+
+It was written just to solve my own problem, but in a general way, that
+turned out to be useful in lots of other situations. So over the first half
+a year or so, it started attracting some early adopters who made some very
+helpful suggestions.
+
+Then I did the git-annex assistant kickstarter, and started blogging about
+each day I worked on it. Four years of funding and seven hundred and twenty
+one posts later, the 
+[git-annex devblog](https://git-annex.branchable.com/devblog/) is still going.
+So, I won't talk about technical details in this post, they've all been
+covered.
+
+One thing I wondered when starting git-annex -- besides whether I would be
+able to write it in Haskell at all -- was would that prevent it from getting
+many patches. I count roughly 65 "thanks" messages in the changelog, so it
+gets perhaps one patch contributed per month. It's hard to say if that's a
+lot or a little.
+
+Part of git-annex is supporting various cloud storage systems via "special
+remotes". Of those not written by me, only 1 was contributed in
+Haskell. Compare with 13 that use the plugin system that lets other
+programming languages be used.
+
+The other question about using Haskell is, did it make git-annex a better
+program. I think it did. The strong type system did prevent plenty of
+bugs, although there have still been some real howlers. The code is
+still *not* taking full advantage of the power of Haskell's type system,
+on the other hand it uses many Haskell libraries that do leverage the type
+system more. I've done more small and large refactorings of git-annex than on
+any other program I've written, because the strong types and 
+[referential transparency](https://wiki.haskell.org/Referential_transparency)
+makes refactoring easier and safer in Haskell. 
+
+And the code has turned out to be much more flexible, for all its static
+types, than the kind of code I was writing before. Examples include
+building the git-annex assistant, which uses the rest of git-annex as a
+library, and making git-annex run actions concurrently, thanks to there
+being no global variables to complicate things (and excellent support
+for concurrency and parallelism in Haskell).
+
+So: Glad I wrote it, glad I used Haskell for it, estatic that many other
+people have found it useful, and astounded that I've been funded to work on
+it for four years.
+
+Next: [[twenty_years_of_free_software_--_part_8_github-backup]]

format
diff --git a/blog/entry/hackerholler.mdwn b/blog/entry/hackerholler.mdwn
index f7d5573..9e89a1c 100644
--- a/blog/entry/hackerholler.mdwn
+++ b/blog/entry/hackerholler.mdwn
@@ -35,7 +35,7 @@ a creek.
 Could we put all this together somehow? Might a handful of my friends
 be able to contribute somewhere in the range of $10 thousand to buy in?
 
-Interested? Want more details? Have ideas?
+Interested? Want more details? Have ideas?  
 <b>Visit the <a href="https://hackerholler.branchable.com/">Hacker Holler website</a>
 and get in touch.</b>
 

add
diff --git a/blog/entry/hackerholler.mdwn b/blog/entry/hackerholler.mdwn
new file mode 100644
index 0000000..f7d5573
--- /dev/null
+++ b/blog/entry/hackerholler.mdwn
@@ -0,0 +1,46 @@
+[[!meta title="Hacker Holler"]]
+
+<img src="https://hackerholler.branchable.com/header_background.png">
+
+A quiet place in which to get away and code is all I was looking for when I
+moved here. I found much more, but that's still the essence of the place.
+
+On returning home from the beach, I've just learned that after
+several years renting this house, I will soon have to leave, or buy it.
+
+<img src="https://hackerholler.branchable.com/michi.png">
+
+The house is an [EarthShip](https://en.wikipedia.org/wiki/Earthship),
+tucked away in its own private holler (as we say here in the Appalachian
+Mtns of Tennessee), below a mountain that is National Forest, two
+miles down back roads from a river.
+
+A wonderful place to relax and code, but 
+[[developing only free software for twenty years|twenty_years_of_free_software_--_part_1_ikiwiki]]
+doesn't quite stretch to being able to afford buying this kind of place.
+
+But, I got to thinking of times friends were able to visit me here.
+Grilling over wood fires with friends from Debian. Steep hikes and river
+swims. Sharing dialup bandwidth between our Linux laptops. A bunch of us
+discussing Haskell in the living room at midnight. And too, I've many times
+talked about the place with someone who got a gleam in their eye, imagining
+themselves living there.
+
+And then there's [my Yurt](http://joeyh.name/yurt/), my relief valve before
+I moved here. And a great spot I like to visit on an old logging road above
+a creek.
+
+<a href="https://joeyh.name/yurt/"><img src="https://joeyh.name/blog/pics/snowyurt.jpg"></a>
+
+Could we put all this together somehow? Might a handful of my friends
+be able to contribute somewhere in the range of $10 thousand to buy in?
+
+Interested? Want more details? Have ideas?
+<b>Visit the <a href="https://hackerholler.branchable.com/">Hacker Holler website</a>
+and get in touch.</b>
+
+(Limited to folks I've met in person or spent a lot of time online with.)
+
+<img src="https://hackerholler.branchable.com/woodstove.jpg">
+
+[[!meta author=Joey]]

add
diff --git a/blog/entry/twenty_years_of_free_software_--_part_6_moreutils.mdwn b/blog/entry/twenty_years_of_free_software_--_part_6_moreutils.mdwn
new file mode 100644
index 0000000..fcaa3ee
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_6_moreutils.mdwn
@@ -0,0 +1,23 @@
+[[code/moreutils]] is a little love letter to the Unix Tools philosophy.
+It was interesting to try to find new tools as basic as `cat` and `ls`.
+With `sponge` and `vidir` and `ifne` and `chronic` and others, we managed
+to find several such tools.
+
+So, it was fun to work on moreutils, but it also ran into inherent problems
+with the Unix Tools philosophy. One is namespacing; there are only so many
+good short names for commands, and a command like `parallel` can easily
+collide with something else. And since Unix Tools have a bigger surface
+area than a pure function, my `parallel` is not going to be quite compatible
+with your `parallel`, even if they were developed with (erm) parallel
+intentions.
+
+Partly due to that problem, I have gotten pickier about adding new tools to
+moreutils as it's gotten older, and so there's a lot of suggested additions
+that I will probably never get to.
+
+And as my mention of pure functions suggests, I have kind of moved on from
+being a big fan of the Unix Tools philosophy. Unix tools are a decent
+approximation of pure functions for their time, but they are not really
+pure, and not typed at all, and not usefully namespaced, and this limits them.
+
+Next: [[twenty_years_of_free_software_--_part_7_git-annex]]

poll vote (I tried it, liked it.)
diff --git a/code/kaxxt/feedback.mdwn b/code/kaxxt/feedback.mdwn
index 760f077..4cbcfba 100644
--- a/code/kaxxt/feedback.mdwn
+++ b/code/kaxxt/feedback.mdwn
@@ -1,4 +1,4 @@
 Whatdayathink? Please vote in the poll, or post your
 experiences/questions to [[/code/Kaxxt/Discussion]].
 
-[[!poll 3 "I tried it, liked it." 0 "I tried it, needs work." 9 "I haven't tried it, but want to" 2 "I don't plan to try it"]]
+[[!poll 4 "I tried it, liked it." 0 "I tried it, needs work." 9 "I haven't tried it, but want to" 2 "I don't plan to try it"]]

blog
diff --git a/blog/entry/twenty_years_of_free_software_--_part_5_pristine-tar.mdwn b/blog/entry/twenty_years_of_free_software_--_part_5_pristine-tar.mdwn
new file mode 100644
index 0000000..8cb78d7
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_5_pristine-tar.mdwn
@@ -0,0 +1,44 @@
+I've written retrospectively about [[code/pristine-tar]] before,
+when I [stopped maintaining it](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737871).
+So, I'll quote part of that here:
+
+	[...] a little bit about the reason I wrote pristine-tar in the
+	first place. There were two reasons:
+	
+	1. I was once in a talk where someone mentioned that Ubuntu had/was
+	   developing something that involved regenerating orig tarballs
+	   from version control.
+	   I asked the obvious question: How could that possibly be done
+	   technically? 
+	   The (slightly hung over) presenter did not have a satesfactory
+	   response, so my curiosity was piqued to find a way to do it.
+	   (I later heard that Ubuntu has been using pristine-tar..)
+	
+	2. Sometimes code can be subversive. It can change people's perspective
+	   on a topic, nudging discourse in a different direction. It can even
+	   point out absurdities in the way things are done. I may or may not
+	   have accomplished the subversive part of my goals with pristine-tar.
+	
+	Code can also escape its original intention. Many current uses of
+	pristine-tar fall into that category. So it seems likely that some
+	people will want it to continue to work even if it's met the two goals
+	above already.
+
+For me, the best part of building pristine-tar was finding an
+answer to the question "How could that possibly be done technically?"
+It was also pretty cool to be able to use every tarball in Debian as the test
+suite for pristine-tar.
+
+I'm afraid I kind of left Debian in the lurch when I stopped maintaining
+pristine-tar.
+
+"Debian has probably hundreds, if not thousands of git repositories using
+pristine-tar. We all rely now on an unmaintained, orphaned, and buggy piece
+of software." -- [Norbert Preining ](https://www.preining.info/blog/2014/06/debian-pristine-tar-packaging/)
+
+So I was relieved when it finally got a new maintainer just recently.
+
+Still, I don't expect I'll ever use pristine-tar again. It's the only
+software I've built in the past ten years that I can say that about.
+
+Next: [[twenty_years_of_free_software_--_part_6_moreutils]]

blog
diff --git a/blog/entry/twenty_years_of_free_software_--_part_4_ikiwiki-hosting.mdwn b/blog/entry/twenty_years_of_free_software_--_part_4_ikiwiki-hosting.mdwn
new file mode 100644
index 0000000..3d238e5
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_4_ikiwiki-hosting.mdwn
@@ -0,0 +1,14 @@
+[[code/ikiwiki-hosting]] is a spin-off from ikiwiki. I wrote it to manage
+many ikiwiki instances for <a href="http://branchable.com/">Branchable</a>,
+and made it free software out of principle.
+
+While Branchable has not reached the point of providing much income, it's
+still running after 6 years. Ikiwiki-hosting makes it pretty easy to
+maintain it, and I host all of my websites there.
+
+A couple of other people have also found ikiwiki-hosting useful, which is
+not only nice, but led to some big improvements to it. Mostly though,
+releasing the software behind the business as free software caused us to
+avoid shortcuts and build things well.
+
+Next: [[twenty_years_of_free_software_--_part_5_pristine-tar]]

Added a comment
diff --git a/blog/entry/twenty_years_of_free_software_--_part_3_myrepos/comment_1_e73cc6424b4c88f5fe2d51dea6808407._comment b/blog/entry/twenty_years_of_free_software_--_part_3_myrepos/comment_1_e73cc6424b4c88f5fe2d51dea6808407._comment
new file mode 100644
index 0000000..4f9db00
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_3_myrepos/comment_1_e73cc6424b4c88f5fe2d51dea6808407._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://openid.ppke.hu/cstamas"
+ subject="comment 1"
+ date="2016-06-22T23:41:06Z"
+ content="""
+These are all amazing sw. all fill some real need. 
+Thanks for providing them and the maintenance. 
+
+Regards,  
+ Tamas 
+"""]]

link
diff --git a/blog/entry/twenty_years_of_free_software_--_part_3_myrepos.mdwn b/blog/entry/twenty_years_of_free_software_--_part_3_myrepos.mdwn
index 349425b..6bf4166 100644
--- a/blog/entry/twenty_years_of_free_software_--_part_3_myrepos.mdwn
+++ b/blog/entry/twenty_years_of_free_software_--_part_3_myrepos.mdwn
@@ -1,4 +1,4 @@
-[[code/myrepos]] is kind of just an elaborated `foreach (@myrepos)` loop, but
+[[myrepos|code/mr]] is kind of just an elaborated `foreach (@myrepos)` loop, but
 its configuration and extension in a sort of hybrid between an .ini file
 and shell script is quite nice and plenty of other people have found it
 useful.

post
diff --git a/blog/entry/twenty_years_of_free_software_--_part_2_etckeeper.mdwn b/blog/entry/twenty_years_of_free_software_--_part_2_etckeeper.mdwn
index bcc8174..edc40c6 100644
--- a/blog/entry/twenty_years_of_free_software_--_part_2_etckeeper.mdwn
+++ b/blog/entry/twenty_years_of_free_software_--_part_2_etckeeper.mdwn
@@ -16,3 +16,5 @@ from other people to warrant a new release. That happens pretty regularly.
 
 So it's still a minor project as far as I'm concerned, but quite a few
 people seem to be finding it useful. So it goes with free software.
+
+Next: [[twenty_years_of_free_software_--_part_3_myrepos]]
diff --git a/blog/entry/twenty_years_of_free_software_--_part_3_myrepos.mdwn b/blog/entry/twenty_years_of_free_software_--_part_3_myrepos.mdwn
new file mode 100644
index 0000000..349425b
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_3_myrepos.mdwn
@@ -0,0 +1,14 @@
+[[code/myrepos]] is kind of just an elaborated `foreach (@myrepos)` loop, but
+its configuration and extension in a sort of hybrid between an .ini file
+and shell script is quite nice and plenty of other people have found it
+useful.
+
+I had to write myrepos when I switched from subversion to git,
+because git's submodules are too limited to meet my needs, and I needed a
+tool to check out and update many repositories, not necessarily all using
+the same version control system.
+
+It was called "mr" originally, but I renamed the package because it's
+impossible to google for "mr". This is the only software I've ever renamed.
+
+Next: [[twenty_years_of_free_software_--_part_4_ikiwiki-hosting]]

Added a comment: highly valuable code
diff --git a/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_0c100898eda4ceb547e6a35f67bc8154._comment b/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_0c100898eda4ceb547e6a35f67bc8154._comment
new file mode 100644
index 0000000..f61eb62
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_0c100898eda4ceb547e6a35f67bc8154._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="schmonz-web-ikiwiki@025fa2638101a6a9c91816b42707c4dc6ea8ff53"
+ nickname="schmonz-web-ikiwiki"
+ subject="highly valuable code"
+ date="2016-06-22T13:58:01Z"
+ content="""
+Thank you again for ikiwiki. As a user, not only does it appeal to my personal taste (as I explain in [Remembering Textpattern](http://www.schmonz.com/2013/05/27/remembering-textpattern/
+)), but it also it has helped me solve publishing problems I'm not sure I could have solved any other way. In particular, I don't know how else NetBSD (under its [hosting constraints](https://wiki.netbsd.org/wiki/todo/choose_wiki_software/)) would have gotten a wiki in my lifetime.
+
+I'm motivated to extend the useful life of this very valuable software. Round tuits permitting, I hope to incrementally add tests and refactor, to grow my understanding (and help others do the same) of how ikiwiki does what it does, and to make it safer to experiment with -- for instance, with ways of doing more of the processing more concurrently.
+
+A few more posts of appreciation for ikiwiki:
+
+- [Signal and static](http://www.schmonz.com/2015/04/29/signal-and-static/)
+- [Incremental effort, incremental payoff](http://www.schmonz.com/2015/11/04/incremental-effort-incremental-payoff/)
+- [Web Architecture For Unix Lovers](http://www.schmonz.com/2016/04/16/pillarcon-2016-web-architecture-cross-platform-deployment/slides/web-architecture-for-unix-lovers/) (JavaScript slide deck of a lightning talk)
+
+--[schmonz](http://ikiwiki.info/users/schmonz/)
+"""]]

removed
diff --git a/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_0a4fcb00122ebd3562062c0a532dc5a5._comment b/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_0a4fcb00122ebd3562062c0a532dc5a5._comment
deleted file mode 100644
index 7614fab..0000000
--- a/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_0a4fcb00122ebd3562062c0a532dc5a5._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="bronson"
- subject="Part 2"
- date="2016-06-21T17:55:53Z"
- content="""
-Part 2 is here: [http://joeyh.name/blog/entry/twenty_years_of_free_software--part_2_etckeeper/](http://joeyh.name/blog/entry/twenty_years_of_free_software--part_2_etckeeper/)
-"""]]

update
diff --git a/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki.mdwn b/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki.mdwn
index 4fa8330..b2c44bd 100644
--- a/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki.mdwn
+++ b/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki.mdwn
@@ -43,3 +43,5 @@ Ikiwiki has several developers now, and I'm the least active of them. I
 stepped back because I can't write Perl very well anymore, and am mostly
 very happy with how Ikiwiki works, so only pop up now and then when
 something annoys me.
+
+Next: [[twenty_years_of_free_software_--_part_2_etckeeper]]

Added a comment: Part 2
diff --git a/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_0a4fcb00122ebd3562062c0a532dc5a5._comment b/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_0a4fcb00122ebd3562062c0a532dc5a5._comment
new file mode 100644
index 0000000..7614fab
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_0a4fcb00122ebd3562062c0a532dc5a5._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="bronson"
+ subject="Part 2"
+ date="2016-06-21T17:55:53Z"
+ content="""
+Part 2 is here: [http://joeyh.name/blog/entry/twenty_years_of_free_software--part_2_etckeeper/](http://joeyh.name/blog/entry/twenty_years_of_free_software--part_2_etckeeper/)
+"""]]

removed
diff --git a/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_c8580ff60fe980bd0a1a54927d564faf._comment b/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_c8580ff60fe980bd0a1a54927d564faf._comment
deleted file mode 100644
index 7ac1668..0000000
--- a/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_c8580ff60fe980bd0a1a54927d564faf._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="bronson"
- subject="Part 2"
- date="2016-06-21T17:54:44Z"
- content="""
-Part 2 is here: http://joeyh.name/blog/entry/twenty_years_of_free_software_--_part_2_etckeeper/
-"""]]

Added a comment: Part 2
diff --git a/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_c8580ff60fe980bd0a1a54927d564faf._comment b/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_c8580ff60fe980bd0a1a54927d564faf._comment
new file mode 100644
index 0000000..7ac1668
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/comment_1_c8580ff60fe980bd0a1a54927d564faf._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="bronson"
+ subject="Part 2"
+ date="2016-06-21T17:54:44Z"
+ content="""
+Part 2 is here: http://joeyh.name/blog/entry/twenty_years_of_free_software_--_part_2_etckeeper/
+"""]]

post
diff --git a/blog/entry/twenty_years_of_free_software_--_part_2_etckeeper.mdwn b/blog/entry/twenty_years_of_free_software_--_part_2_etckeeper.mdwn
new file mode 100644
index 0000000..bcc8174
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_2_etckeeper.mdwn
@@ -0,0 +1,18 @@
+[[code/etckeeper]] was a sleeper success for me. I created it, wrote one
+blog post about it, installed it on all my computers, and mostly forgot
+about it, except when I needed to look something up in the git history
+of /etc it helpfully maintains. It's a minor project.
+
+Then I started getting patches porting it to many other version control
+systems, and other linux distributions, and fixing problems, and adding
+features. Mountains and mountains of patches over time.
+
+And then I started hearing about distributions that install it by default.
+(Though Debian for some reason never did so I keep having to install it
+everywhere by hand.)
+
+Writing this blog post, I noticed etckeeper had accumulated enough patches
+from other people to warrant a new release. That happens pretty regularly.
+
+So it's still a minor project as far as I'm concerned, but quite a few
+people seem to be finding it useful. So it goes with free software.

post
diff --git a/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki.mdwn b/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki.mdwn
new file mode 100644
index 0000000..4fa8330
--- /dev/null
+++ b/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki.mdwn
@@ -0,0 +1,45 @@
+I'm forty years old. I've been developing free software for twenty years.
+
+A decade ago, I wrote a series of posts about my first
+[[ten_years_of_free_software|ten_years_of_free_software_--_part_1_pdmenu]],
+looking back over projects I'd developed. These retrospectives seem even more
+valuable in retrospect; there are things in the old posts that jog my memory,
+and other details I've forgotten by now.
+
+So, I'm doing it again. Over the next two weeks (with a week off in the middle
+for summer vacation), I'll be writing one post each day about a free software
+project I've developed in the past decade.
+
+-----------------------------------------------------------------------------
+
+We begin with [[code/Ikiwiki]]. I started it 10 years ago, and still use it
+to this day; it's the engine that builds this website, and nearly all
+my other websites, as well as wikis and websites belonging to tons and
+tons of other projects, like NetBSD, X.org, Freedesktop.org, FreedomBox and 
+[many other users](http://Ikiwiki.info/Ikiwikiusers).
+
+Indeed I'm often reading a website and find myself wondering "hey.. is this
+using Ikiwiki?", and glance at the html and find that yes, it is. So,
+Ikiwiki is a reasonably successful and widely used peice of software,
+at least in its niche.
+
+More important to me, it was a static site generator before we knew what
+those were. It wasn't the first, but it broke plenty of new ground. I'm
+particularly proud of the way it combines a wiki with blogging support
+seamlessly, and the incremental updating of the static pages including
+updating wikilinks and backlinks. Some of these and other features are
+still pretty unique to Ikiwiki despite the glut of other static site
+generators available now.
+
+Ikiwiki is written in Perl, which was great for getting lots of other
+contributions (including many of its 113 plugins), but has also held it
+back some lately. There are less Perl programmers these days. And over the
+past decade, concurrency has become very important, but Ikiwiki's
+implementation is stubbornly single threaded, and multithreading such a
+Perl program is a losing propoisition. I occasionally threaten to rewrite
+it in Haskell, but I doubt I will.
+
+Ikiwiki has several developers now, and I'm the least active of them. I
+stepped back because I can't write Perl very well anymore, and am mostly
+very happy with how Ikiwiki works, so only pop up now and then when
+something annoys me.

update
diff --git a/code.mdwn b/code.mdwn
index a00686f..ee38075 100644
--- a/code.mdwn
+++ b/code.mdwn
@@ -15,7 +15,6 @@ The stuff that's swapped into my local cache at the moment.
 [[ikiwiki-hosting]]
 [[github-backup]]
 [[shell-monad]]
-[[brainfuck-monad]]
 
 ## Less active projects
 
@@ -26,6 +25,7 @@ In maintenance mode mostly, but I still have my hands in it somewhat.
 [[pdmenu]]
 [[filters]]
 [[electrum-mnemonic]]
+[[brainfuck-monad]]
 [[scroll]]
 
 ## Past projects

respo
diff --git a/blog/entry/second_system/comment_2_a88eaf65a59ad1b804a09bf903fd2726._comment b/blog/entry/second_system/comment_2_a88eaf65a59ad1b804a09bf903fd2726._comment
new file mode 100644
index 0000000..1927a71
--- /dev/null
+++ b/blog/entry/second_system/comment_2_a88eaf65a59ad1b804a09bf903fd2726._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-06-16T15:06:36Z"
+ content="""
+It's gravity fed from a spring, so there is not enough water pressure for
+that to be a problem.
+"""]]

Added a comment: Repulsion
diff --git a/blog/entry/second_system/comment_1_e8cd2426f78b91d6a3b2b38f6fcfccd3._comment b/blog/entry/second_system/comment_1_e8cd2426f78b91d6a3b2b38f6fcfccd3._comment
new file mode 100644
index 0000000..063ec66
--- /dev/null
+++ b/blog/entry/second_system/comment_1_e8cd2426f78b91d6a3b2b38f6fcfccd3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="Repulsion"
+ date="2016-06-15T08:18:47Z"
+ content="""
+Nice. But with the suspended shower head, won’t the repulsion of the water stream push it back as you turn it on, so that the showered area keeps moving?
+"""]]

blog
diff --git a/blog/entry/second_system.mdwn b/blog/entry/second_system.mdwn
new file mode 100644
index 0000000..8f86da5
--- /dev/null
+++ b/blog/entry/second_system.mdwn
@@ -0,0 +1,15 @@
+Five years ago [[I built this|outdoor_shower]], and it's worked well, but
+is old and falling down now.
+
+[[!img blog/pics/shower.jpeg caption="mark I outdoor shower"]]
+
+The replacement is more minimalist and like any second system tries to
+improve on the design of the first. No wood to rot away, fully adjustable
+height. It's basically a shower swing, suspended from a tree branch.
+
+[[!img blog/pics/showermk2.jpg caption="mark II outdoor shower"]]
+
+Probably will turn out to have its own new problems, as second systems
+do.
+
+[[!tag lay]]
diff --git a/blog/pics/showermk2.jpg b/blog/pics/showermk2.jpg
new file mode 100644
index 0000000..60dacdb
Binary files /dev/null and b/blog/pics/showermk2.jpg differ

remove shuttleworth logo; grant time over
diff --git a/blog.mdwn b/blog.mdwn
index c3c8d8f..ed4c232 100644
--- a/blog.mdwn
+++ b/blog.mdwn
@@ -10,8 +10,6 @@ actions=yes]]
 <a href="http://flattr.com/thing/39887/Joey-Hesss-blog" target="_blank">
 <img src="https://api.flattr.com/button/flattr-badge-large.png" alt="Flattr this" title="Flattr this" border="0" /></a>
 
-[[!img pics/shuttleworth.jpg size=150x link=shuttleworth-flash-grant]]
-
 [[!calendar pages="blog/entry/* and !blog/entry/*/* and !*/Discussion"]]
 
 [[!calendar pages="blog/entry/* and !blog/entry/*/* and !*/Discussion" year=-1]]
diff --git a/blog/pics/shuttleworth.jpg b/blog/pics/shuttleworth.jpg
deleted file mode 100644
index 33a2b2b..0000000
Binary files a/blog/pics/shuttleworth.jpg and /dev/null differ

update
diff --git a/blog/entry/electrum_ssl_vulnerabilities.mdwn b/blog/entry/electrum_ssl_vulnerabilities.mdwn
index 53bf901..b1b18f1 100644
--- a/blog/entry/electrum_ssl_vulnerabilities.mdwn
+++ b/blog/entry/electrum_ssl_vulnerabilities.mdwn
@@ -5,7 +5,8 @@ Here are two bug reports I filed about it:
 ssl certs with CERT_NONE, allowing MITM</a>
 
 <a href="https://github.com/spesmilo/electrum/issues/1783">fails to verify
-ssl cert hostname for cached certs</a>
+ssl cert hostname for cached certs</a>  
+(update: Seems I was wrong about this bug)
 
 One full month after I filed these, there's been no activity, so I thought
 I'd make this a little more widely known. It's too hard to get CVEs

blog update
diff --git a/blog/entry/electrum_ssl_vulnerabilities.mdwn b/blog/entry/electrum_ssl_vulnerabilities.mdwn
new file mode 100644
index 0000000..53bf901
--- /dev/null
+++ b/blog/entry/electrum_ssl_vulnerabilities.mdwn
@@ -0,0 +1,29 @@
+The electrum bitcoin wallet seems to use SSL insecurely.
+Here are two bug reports I filed about it:
+
+<a href="https://github.com/spesmilo/electrum/issues/1782">ignores invalid
+ssl certs with CERT_NONE, allowing MITM</a>
+
+<a href="https://github.com/spesmilo/electrum/issues/1783">fails to verify
+ssl cert hostname for cached certs</a>
+
+One full month after I filed these, there's been no activity, so I thought
+I'd make this a little more widely known. It's too hard to get CVEs
+assigned, and resgistering a snarky domain name is passe.
+
+I'm not actually using electrum myself currently, as I own no bitcoins.
+I only noticed these vulnerabilities when idly perusing the code.
+I have not tried to actually exploit them, and some of the higher levels of
+the SPV blockchain verification make them difficult to exploit. Or perhaps
+there are open wifi networks where all electrum connections get intercepted
+by a rogue server that successfully uses these security holes to pretend to
+be the entire electrum server network.
+
+I'm not particularly surprised to find code that's supposed to be securing a
+connection with SSL but actually fails to verify the SSL certificate.
+That's the common failure mode of SSL libraries.
+
+It is a bit surprising to find such mistakes in a bitcoin wallet
+though. And, electrum seems to go out of its way to complicate its SSL
+certificate handling, which directly led to these security holes. Kind of
+makes me wonder about the security of the rest of it.

add news item for github-backup 1.20160522
diff --git a/code/github-backup/news/version_1.20150618.mdwn b/code/github-backup/news/version_1.20150618.mdwn
deleted file mode 100644
index 6b77b0d..0000000
--- a/code/github-backup/news/version_1.20150618.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-github-backup 1.20150618 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Fix broken configure script."""]]
\ No newline at end of file
diff --git a/code/github-backup/news/version_1.20160522.mdwn b/code/github-backup/news/version_1.20160522.mdwn
new file mode 100644
index 0000000..fb4a64b
--- /dev/null
+++ b/code/github-backup/news/version_1.20160522.mdwn
@@ -0,0 +1,12 @@
+github-backup 1.20160522 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Work around git weirdness in handling of relative path to GIT\_INDEX\_FILE
+     when in a subdirectory of the repository.
+   * Various updates to internal git and utility libraries shared
+     with git-annex.
+   * debian: Add lintian overrides for rpath.
+   * debian: Bump standards-version.
+   * Makefile: Pass LDFLAGS, CFLAGS, and CPPFLAGS through ghc and on to
+     ld, cc, and cpp. This lets the Debian package build with various
+     hardening options. Although their benefit to a largely haskell program
+     is unknown."""]]
\ No newline at end of file

yay, new pristine-tar maintainer
diff --git a/code.mdwn b/code.mdwn
index 4f13c93..a00686f 100644
--- a/code.mdwn
+++ b/code.mdwn
@@ -42,6 +42,7 @@ people have taken them on.
 [[debconf]]
 [[dpkg-repack]]
 [[os-prober]]
+[[pristine-tar]]
 [[devscripts]]
 [[pentium-builder]]
 [[apt-src]]
@@ -51,7 +52,6 @@ These need new maintainers, stat!
 
 [[debmirror]]
 [[sleepd]]
-[[pristine-tar]]
 [[alien]]
 [[nslu2-utils]]
 [[ticker]]
diff --git a/code/pristine-tar.mdwn b/code/pristine-tar.mdwn
index 9f54d66..d7153ff 100644
--- a/code/pristine-tar.mdwn
+++ b/code/pristine-tar.mdwn
@@ -10,11 +10,8 @@ the source code, thus allowing the original tarball to be extracted from
 revision control.
 
 pristine-tar is available in git at
-`git://git.joeyh.name/pristine-tar/`
+`http://anonscm.debian.org/cgit/collab-maint/pristine-tar.git`
 
 It's also in Debian.
 
-[[!sidebar content="""
-<a href="http://flattr.com/thing/39934/pristine-tar" target="_blank">
-<img src="http://api.flattr.com/button/button-static-50x60.png" alt="Flattr this" title="Flattr this" border="0" /></a>
-"""]]
+(I am no longer maintaining pristine-tar, it has a new maintainer now.)

Added a comment: git snapshot?
diff --git a/blog/entry/our_beautiful_fake_histories/comment_5_175f17e67d1dbb21824dad77bf3606c6._comment b/blog/entry/our_beautiful_fake_histories/comment_5_175f17e67d1dbb21824dad77bf3606c6._comment
new file mode 100644
index 0000000..b21e849
--- /dev/null
+++ b/blog/entry/our_beautiful_fake_histories/comment_5_175f17e67d1dbb21824dad77bf3606c6._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="jeremy@9671a7e35b1a900e0188905cecb40ee1e209025a"
+ nickname="jeremy"
+ subject="git snapshot?"
+ date="2016-05-20T10:18:12Z"
+ content="""
+That's why I threw this together;
+https://github.com/lakeman/git-snapshot
+
+The best of both worlds. Add it to your make process to preserve the contents of your working folder, while leaving your HEAD commit alone so you can keep trying to write a more beautiful history.
+
+Never used it myself, and it definitely needs more work to be useful in the real world.
+"""]]

update
diff --git a/code/wmbattery.mdwn b/code/wmbattery.mdwn
index 6c6b206..06cef76 100644
--- a/code/wmbattery.mdwn
+++ b/code/wmbattery.mdwn
@@ -23,8 +23,10 @@ some improvements in wmbattery:
 * Support for getting battery status from the sonypi driver instead of APM, for some Sony laptops that do not have apm support.
 * Can make its own estimatess of time remaining or time until full charge, even if APM does not.
 
-`wmbattery` is available as a Debian package or in git
-(`git://git.joeyh.name/zzattic/wmbattery`).
+I have passed on maintenance of wmbattery to Doug Torrance,
+and it has a new home page here: <http://windowmaker.org/dockapps/?name=wmbattery>
+
+(My old and no longer maintained git repository: `git://git.joeyh.name/zzattic/wmbattery`)
 
 I posted some 
 [[thoughts_and_history_about_wmbattery|blog/entry/ten_years_of_free_software_--_part_7_wmbattery]]

update
diff --git a/code/kaxxt/discussion.mdwn b/code/kaxxt/discussion.mdwn
index 96aa739..80acfb7 100644
--- a/code/kaxxt/discussion.mdwn
+++ b/code/kaxxt/discussion.mdwn
@@ -10,5 +10,5 @@ ashbb
 
 > I don't know. :) My gut feeling is either the larger pyramid will, or the
 > laser will have spread out and both matching pyramids can combine to
-> catch it. In the latter case, we now have a way to split the beam
-> into two, which could get interesting... --[[Joey]]
+> catch it. In the latter case, the two pyramids can direct the now-split
+> beam to two different places. --[[Joey]]

comment
diff --git a/code/kaxxt/discussion.mdwn b/code/kaxxt/discussion.mdwn
index 55e4cb3..96aa739 100644
--- a/code/kaxxt/discussion.mdwn
+++ b/code/kaxxt/discussion.mdwn
@@ -7,3 +7,8 @@ Hi. I have a question about the advanced example.
 - Which yellow pyramid, small or medium, will catch the laser?
 
 ashbb
+
+> I don't know. :) My gut feeling is either the larger pyramid will, or the
+> laser will have spread out and both matching pyramids can combine to
+> catch it. In the latter case, we now have a way to split the beam
+> into two, which could get interesting... --[[Joey]]

fix
diff --git a/code/kaxxt.mdwn b/code/kaxxt.mdwn
index e66eec6..a1e85b2 100644
--- a/code/kaxxt.mdwn
+++ b/code/kaxxt.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Kaxxt (on Ice) # prototype"]]
 
-[[!inline feeds=no pagenames="code/kaxxt/introduction code/kaxxt/what_you_need how_to_play
+[[!inline feeds=no pagenames="code/kaxxt/introduction code/kaxxt/what_you_need code/kaxxt/how_to_play
 code/kaxxt/pyramid_power code/kaxxt/stack_overflows code/kaxxt/hacks code/kaxxt/strategy code/kaxxt/feedback code/kaxxt/TODO" template=bareinlinepage]]
 
 ----

fix
diff --git a/code/kaxxt.mdwn b/code/kaxxt.mdwn
index 3ea4614..e66eec6 100644
--- a/code/kaxxt.mdwn
+++ b/code/kaxxt.mdwn
@@ -1,7 +1,7 @@
 [[!meta title="Kaxxt (on Ice) # prototype"]]
 
-[[!inline feeds=no pages="introduction what_you_need how_to_play
-pyramid_power stack_overflows hacks strategy feedback TODO" template=bareinlinepage]]
+[[!inline feeds=no pagenames="code/kaxxt/introduction code/kaxxt/what_you_need how_to_play
+code/kaxxt/pyramid_power code/kaxxt/stack_overflows code/kaxxt/hacks code/kaxxt/strategy code/kaxxt/feedback code/kaxxt/TODO" template=bareinlinepage]]
 
 ----
 

fix
diff --git a/code/kaxxt.mdwn b/code/kaxxt.mdwn
index 8799d7b..3ea4614 100644
--- a/code/kaxxt.mdwn
+++ b/code/kaxxt.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Kaxxt (on Ice) # prototype"]]
 
-[[!inline feeds=no pagenames="introduction what_you_need how_to_play
+[[!inline feeds=no pages="introduction what_you_need how_to_play
 pyramid_power stack_overflows hacks strategy feedback TODO" template=bareinlinepage]]
 
 ----

comment
diff --git a/blog/entry/introducing_mr/comment_2_0dba26c2182b424028c4002b0daa627c._comment b/blog/entry/introducing_mr/comment_2_0dba26c2182b424028c4002b0daa627c._comment
new file mode 100644
index 0000000..3301978
--- /dev/null
+++ b/blog/entry/introducing_mr/comment_2_0dba26c2182b424028c4002b0daa627c._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-12T18:47:52Z"
+ content="""
+<http://myrepos.branchable.com/todo/>
+"""]]

Added a comment: Issue tracker
diff --git a/blog/entry/introducing_mr/comment_1_835eb504d7e0d6a6542e6af07e6a1217._comment b/blog/entry/introducing_mr/comment_1_835eb504d7e0d6a6542e6af07e6a1217._comment
new file mode 100644
index 0000000..5363fa3
--- /dev/null
+++ b/blog/entry/introducing_mr/comment_1_835eb504d7e0d6a6542e6af07e6a1217._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://jakoblog.de/"
+ nickname="jakob"
+ subject="Issue tracker"
+ date="2016-05-12T15:11:27Z"
+ content="""
+Where can users contribute bug reports and feature requests? In particular I miss
+
+    mr unregister repository # remove repository from .mrconfig
+    mr unregister --missing  # remove all deleted repositories from .mrconfig
+
+    mr register *            # register multiple repositories
+
+
+    
+"""]]

add news item for github-backup 1.20160511
diff --git a/code/github-backup/news/version_1.20150617.mdwn b/code/github-backup/news/version_1.20150617.mdwn
deleted file mode 100644
index 464e357..0000000
--- a/code/github-backup/news/version_1.20150617.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-github-backup 1.20150617 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Add missing build deps for windows to cabal file.
-     Thanks, Jeff Segal.
-   * Various updates to internal git and utility libraries shared
-     with git-annex."""]]
\ No newline at end of file
diff --git a/code/github-backup/news/version_1.20160511.mdwn b/code/github-backup/news/version_1.20160511.mdwn
new file mode 100644
index 0000000..45896fa
--- /dev/null
+++ b/code/github-backup/news/version_1.20160511.mdwn
@@ -0,0 +1,4 @@
+github-backup 1.20160511 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Fix build with directory-1.2.6.2.
+   * github-backup.cabal: Add Setup-Depends."""]]
\ No newline at end of file

blog update
diff --git a/blog/entry/my_Shuttleworth_Foundation_flash_grant.mdwn b/blog/entry/my_Shuttleworth_Foundation_flash_grant.mdwn
new file mode 100644
index 0000000..2d6d395
--- /dev/null
+++ b/blog/entry/my_Shuttleworth_Foundation_flash_grant.mdwn
@@ -0,0 +1,31 @@
+Six months ago I received a 
+[small grant from the Shuttleworth Foundation](https://shuttleworthfoundation.org/flashgrants/)
+with no strings attached other than I should write this blog post about it.
+That was a nice surprise.
+
+The main thing that ended up being supported by the grant was work on
+[Propellor](https://propellor.branchable.com/), my configuration management
+system that is configured by writing Haskell code. I made 11 releases
+of Propellor in the grant period, with some improvements from me, and lots 
+more from other contributors. The biggest feature that I added to
+Propellor was [[LetsEncrypt support|letsencrypt_support_in_propellor]].
+
+More important than features is making Propellor prevent more classes of
+mistakes, by creative use of the type system. The biggest improvement
+in this area was
+[[type checking the OSes of Propellor properties|type_safe_multi-OS_Propellor]],
+so Propellor can reject host configurations that combine eg, Linux-only
+and FreeBSD-only properties.
+
+Turns out that the same groundwork needed for that is also what's needed
+to get Propellor to do type-level port conflict detection. I have 
+[a branch underway](http://propellor.branchable.com/todo/type_level_port_conflict_detection/)
+that does that, although it's not quite done yet.
+
+The grant also funded some of my work on git-annex. My main funding for
+git-annex doesn't cover development of the git-annex assistant, so the
+grant filled in that gap, particularly in updating the assistant to support
+[[the git-annex v6 repo format|git-annex_v6]].
+
+I've very happy to have received this grant, and with the things it enabled
+me to work on.
diff --git a/code/realtime/design.mdwn b/code/realtime/design.mdwn
index 3f7382a..eaedc43 100644
--- a/code/realtime/design.mdwn
+++ b/code/realtime/design.mdwn
@@ -221,3 +221,61 @@ that its owner has a lot of control over.
 Programming tech could be a similar roguelike minigame to having a
 conversation with an actor. This would basically build up a finite state
 machine that is used to drive the tech.
+
+## user interface
+
+Limit UI to work on lowest common demoninator systems:
+
+* 80x25
+* ascii
+* colors for emphasis but not sole indication of what's where
+
+While this is a rouguelike, it's not one that uses a ton of special keys.
+Movement is via arrow keys. Selection of actions is through menus.
+Have a left-side menu that's always present, and tab switches focus
+between the viewport and the menu.
+
+      scrolling                      date  
+      message                        date  
+      area                           date  
+      [M]ore    ###################|date|###
+      [I]nventy #                          #
+      [B]obble  #                          #
+      [ ]       #                          #
+      [ ]       #             @            #
+      [ ]       #                          #
+      [P]hone   #                          #
+      [ ]       #                          #
+                ########|Region name|#######
+
+Menu items have hotkeys for easy selection (without needing to tab to
+the menu).
+
+The scrolling message area is at least 3 lines tall, and grows to occupy
+any spare lines in the screen. The "[M] more" menu item shows up
+when more than its height in messages are added in a turn.
+
+Each message is dated, and there's also a current date display.
+
+Messages could also contain prompts for additional actions that can only be
+performed shortly after the message appears. These would use a similar UI to
+menu items, so the message area and menu area kind of blur together.
+For example:
+
+    He doesn't seem swayed by your arguments.       20 May 2166
+    [B]ribe him, or [A]rgue on?
+                ###################################|20 May 2166]##
+    [I]nventory #                                                #
+
+The user interface should also work in tablet mode; clicks on menu items
+select them, and clicks around the @ move the @ toward the click.
+
+Some things may prompt for text (eg names); if so a default should always
+be provided so tablet users don't need to enter text.
+
+When prompting for a number, eg how long to bobble up for, do it using a
+menu of reasonable choices with perhaps an "other ..."
+
+## funding
+
+Kickstarter?

updates^
diff --git a/code/realtime/design.mdwn b/code/realtime/design.mdwn
index 208c3e9..3f7382a 100644
--- a/code/realtime/design.mdwn
+++ b/code/realtime/design.mdwn
@@ -6,7 +6,7 @@ _Marooned in Realtime_.
 ## Goal
 
 Convince the bobbled remainders of humanity to unify and re-make
-a civilization.
+a civilization, instead of dispersing off into the future.
 
 ## Intro
 
@@ -17,16 +17,6 @@ compared to many others who started nearer to that point.
 
 ## Setting
 
-### Region
-
-The roguelike map should cover a relatively small region. Many bobbles have
-ended up here due to historial reasons (perhaps because the area has a
-stable geography). Around a dozen bobbles should fit on the screen.
-
-Topography: The region will often be a coastline, or contain a river, or be a
-valley in mountains. These large-scale features will be displayed in the
-region.
-
 ### Compounds
 
                           ...
@@ -43,20 +33,64 @@ per room. Avoids needing map generation, etc. Each room has a name
 (storeroom, kitchen, etc), and appropriate starting contents. Center room
 is always control room.
 
+### Region
+
+The roguelike map should cover a relatively small region. Many bobbles have
+ended up here due to historial reasons (perhaps because the area has a
+stable geography). Around a dozen bobbles should fit on the screen.
+
+Topography: The region will often be a coastline, or contain a river, or be a
+valley in mountains. These large-scale features will be displayed in the
+region, along with the bobbles and perhaps other things (ruins, etc) in it.
+
+      #######################################################################
+      #            ^ ^                          ~~~                         #
+      #          ^ ^ ^                         ~~~                          #
+      #           ^ ^ ^                       ~~~                           #
+      #            ^  ^            ...        ~~~                           #
+      #     .        ^            .....      ~~~                            #
+      #    .C.     ^ ^  ^         ..B..     ~~~                           ^ #
+      #     .       ^ ^ ^         .....     ~~~                         ^  ^#
+      #            ^ ^  ^          ...      ~~~                        ^ ^  #
+      #            ^ ^ ^                   ~~~                        ^ ^ ^ #
+      #           ^ ^ ^   ...             ~~~                       ^ ^     #
+      #         ^ ^      .....          ~~~                        ^ ^ ^    #
+      #        ^ ^ ^    .......       ~~~    ...                  ^ ^ ^     #
+      #   ^^ ^ ^ ^ ^    ...A...     ~~~     .....      .        ^ ^  ^      #
+      #  ^  ^ ^ ^ ^     .......   ~~~       ..@..     .D.      ^ ^ ^^       #
+      #  ^ ^ ^           .....    ~~~       .....      .      ^ ^ ^^        #
+      #   ^ ^             ...    ~~~         ...               ^ ^          #
+      #   ^  ^                   ~~~                            ^ ^         #
+      #   ^ ^                   ~~~                              ^ ^        #
+      #######################################################################
+
+Here the player @ can easily visit D, but the river (~) blocks easy access 
+to A and B. And, C is isolated from everything by the mountians (^).
+
+Bobbles can get stuck in a an ocean, or underground, and will then be
+unable to unbobble until time changes the topography, or until rescued.
+(Safety mechanisms immediately re-bobble when in such a situation.) A
+bobble in a river should reroute the river around it.
+
 ### World / Universe
 
-Avoid needing to generate a full consistent world map (or more),
-but other bobbles can be located in other settings, and bobbles
-can be moved (by appropriate tech). 
+There's not a single region; other bobbles can be located in other regions,
+and bobbles can be moved (by appropriate tech). 
 
 ### Inter region movement
 
+Regions have names, which start as some general description of their
+contents such as "verdant river valley" for the above, or eg, "ruins of
+Smithville". The user can rename a region. Each region's name must be unique.
+
 When the user moves outside the local region, query where they're going,
 and let them try to travel there, but in an abstract, non-roguelike manner.
 For example, attempt to walk to some other known region, which may take
 months or years (game time). Or, fly to other region, which may take
-minures. Or, explore for X days looking for a region containing a lake,
-river, mountain, coast, etc.
+minutes. Or, explore for X days looking for a region containing a lake,
+river, mountain, coast, etc. This avoids needing a full considtent world
+map connecting regions, which would be pretty hard to implement and
+represent. It also allows regions to not all be on earth.
 
 With sufficient tech, it's possible to move an entire compound, or a 
 bobble to another region. Same inter-region movement applies.
@@ -69,7 +103,7 @@ regions.
 Game time is key. The game clock starts 100 years in the future from when
 the user runs the game. Bobbling can move it forward in arbitrary leaps.
 Movement within a region moves it forward in minutes or hours. Inter-region
-movement in minutes to mutiple years.
+movement in minutes (with tech) to mutiple years.
 
 Age is the most important stat. Reach old age, die, and game is over,
 win or lose. Tech can of course extend lifespans, somewhat.
@@ -103,21 +137,17 @@ tech allows fine-tuning this.
 * Bobble-in-bobble? I forget if the book allowed this, offensively,
   and/or defensively.
 
-### tech
-
-Tech tree, items with abilities, seems good enough.
-
-### actors
+## actors
 
 A massive part of the game.
 
 (Any way to have multiple player characters? Seems sorta doable; the game
 in multiplayer could be played turn-based, with whichever player is
-furthest back in time being able to act. When players reach the same time,
-they can interact. But, this would require other goals for other players,
-unless cooperative play makes sense. If a player decides their goal is to
-go forward until the sun explodes, they're probably kind of out of the rest
-of the game.)
+furthest back in time being able to act, and when players are at the same
+point in time they could move around in their regions, and can interact.
+But, this would require other goals for other players, unless cooperative
+play makes sense. If a player decides their goal is to go forward until the
+sun explodes, they're probably kind of out of the rest of the game.)
 
 actors have:
 
@@ -133,7 +163,7 @@ actors have:
 * A shorterm goal. ("kill so-and-so", "take such-and-such", "explore region
   for a week)")
 * Trust levels for every other actor, which change as circumstances change.
-* Value placed on every other actor, which change as circumstances change.
+* Value placed on every other actor, which changes as circumstances change.
   (Ie, might not trust someone much, but highly value them for whatever
   reason.)
 * Alliances and agreements with other actors. 
@@ -157,7 +187,7 @@ How to implement this stuff? I want scenarios like:
   `min (B is due to unbobble next) (100 years)`, and if B is unbobbled then,
   will go out to steal from them.
 
-## conversation system
+### conversation system
 
 Crazy idea: Make having a conversation with an actor be a roguelike
 minigame. Items could represent conversational gambits, and rooms topics of
@@ -175,3 +205,19 @@ You destroy the Flawed Argument with your +2 Logic!
 You trip over an emotional mine. It explodes! Movement is difficult.
 The self-forfulling prophecy grabs you. You are being crushed!
 
+### tech
+
+Tech tree, from relatively prosiac items, up to items produced very near
+the singularity. The power increases exponentially.
+
+Some tech items just grant abilities, like the ability to tell when a
+bobble will pop, or the ability to move quickly between regions, have
+telepresense, move bobbles up to a certian size, or destroy other tech.
+
+Other tech needs to be programmable, so it can be used when its owner is
+bobbled, or in a different region. Such tech is kind of an actor, just one
+that its owner has a lot of control over.
+
+Programming tech could be a similar roguelike minigame to having a
+conversation with an actor. This would basically build up a finite state
+machine that is used to drive the tech.

Added a comment: Super promising.
diff --git a/blog/entry/propelling_disk_images/comment_2_806790fb58cec5e9b4c77883c0c388c4._comment b/blog/entry/propelling_disk_images/comment_2_806790fb58cec5e9b4c77883c0c388c4._comment
new file mode 100644
index 0000000..23f137b
--- /dev/null
+++ b/blog/entry/propelling_disk_images/comment_2_806790fb58cec5e9b4c77883c0c388c4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="frederik@ffbea6a549cb3f460d110386c0f634c1ddc6a68a"
+ nickname="frederik"
+ subject="Super promising."
+ date="2016-04-20T14:03:22Z"
+ content="""
+A year ago, I used d-i preseeding to accomplish a [headless install of a Lime2 board](http://www.vanrenterghem.biz/Linux/Installing_Debian_on_Lime2.shtml). I now have a Micro ordered - I don't suppose you implemented that u-boot setup yet? Either way, great stuff.
+
+-- Frederik
+"""]]

Added a comment: mairix 0.23+git20131125-0.5
diff --git a/blog/entry/moving_my_email_archives_and_packages_to_git-annex/comment_1_53c142df8db7b68f10d89d500a330dc4._comment b/blog/entry/moving_my_email_archives_and_packages_to_git-annex/comment_1_53c142df8db7b68f10d89d500a330dc4._comment
new file mode 100644
index 0000000..2c8539e
--- /dev/null
+++ b/blog/entry/moving_my_email_archives_and_packages_to_git-annex/comment_1_53c142df8db7b68f10d89d500a330dc4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="mairix 0.23+git20131125-0.5"
+ date="2016-04-15T23:02:07Z"
+ content="""
+The version of mairix incoming to Debian unstable has been patched so that including `follow_mbox_symlinks` in your `.mairixrc` will restore mairix following symlinks to mboxes.
+"""]]

add news item for moreutils 0.59
diff --git a/code/moreutils/news/version_0.54.mdwn b/code/moreutils/news/version_0.54.mdwn
deleted file mode 100644
index fd13712..0000000
--- a/code/moreutils/news/version_0.54.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-moreutils 0.54 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * vidir: Fix bug in handling filenames that share a common
-     prefix when renaming. Closes: #[654326](http://bugs.debian.org/654326)
-     Thanks, Kushal Kumaran"""]]
\ No newline at end of file
diff --git a/code/moreutils/news/version_0.59.mdwn b/code/moreutils/news/version_0.59.mdwn
new file mode 100644
index 0000000..1d39e7b
--- /dev/null
+++ b/code/moreutils/news/version_0.59.mdwn
@@ -0,0 +1,10 @@
+moreutils 0.59 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Makefile: add DOCBOOKXSL setting.
+     Thanks, Kevin Bullock
+   * parallel: include signal.h to fix warning when building with clang
+     Thanks, Kevin Bullock
+   * chronic: Added -v option for more verbose output.
+     Thanks, Tomas Mudrunka
+   * chronic: Added -e option to display any stderr.
+     Thanks, Tomas Mudrunka"""]]
\ No newline at end of file

switching to git.joeyh.name
diff --git a/blog/entry/a_programmable_alarm_clock_using_systemd.mdwn b/blog/entry/a_programmable_alarm_clock_using_systemd.mdwn
index e5b9148..687981d 100644
--- a/blog/entry/a_programmable_alarm_clock_using_systemd.mdwn
+++ b/blog/entry/a_programmable_alarm_clock_using_systemd.mdwn
@@ -1,5 +1,5 @@
 I've taught my laptop to wake up at 7:30 in the morning. When it does, it
-will run [whatever's in my ~/bin/goodmorning script](http://git.kitenet.net/?p=joey/home.git;a=blob;f=bin/goodmorning;h=567f50f0595c6111bc416c0e5b2dd1de09214790;hb=HEAD). Then, if the lid is
+will run [whatever's in my ~/bin/goodmorning script](http://git.joeyh.name/?p=joey/home.git;a=blob;f=bin/goodmorning;h=567f50f0595c6111bc416c0e5b2dd1de09214790;hb=HEAD). Then, if the lid is
 still closed, it will go back to sleep again.
 
 So, it's a programmable alarm clock that doesn't need the laptop to be left
diff --git a/blog/entry/announcing_etckeeper.mdwn b/blog/entry/announcing_etckeeper.mdwn
index 4e3b0bc..6fdb6fc 100644
--- a/blog/entry/announcing_etckeeper.mdwn
+++ b/blog/entry/announcing_etckeeper.mdwn
@@ -34,7 +34,7 @@ so I can't upload packages, but both it and metastore can be built from git
 easily enough:
 
 	git clone git://git.hardeman.nu/metastore.git; cd metastore; dpkg-buildpackage
-	git clone git://git.kitenet.net/etckeeper; cd etckeeper; dpkg-buildpackage
+	git clone git://git.joeyh.name/etckeeper; cd etckeeper; dpkg-buildpackage
 
 (Update: Now uploaded to unstable.)
 
diff --git a/blog/entry/announcing_olduse.net.mdwn b/blog/entry/announcing_olduse.net.mdwn
index 66030d7..9d017b2 100644
--- a/blog/entry/announcing_olduse.net.mdwn
+++ b/blog/entry/announcing_olduse.net.mdwn
@@ -51,7 +51,7 @@ Usenet's flowering.
   12 hours. When I realized I also needed an A-News to B-News converter,
   I knew it was worth it to have done things right, because that took
   only 43 more lines, and worked 100% on the first run!
-  My code repository for olduse.net is [here](http://git.kitenet.net/?p=oldusenet.git;a=summary).
+  My code repository for olduse.net is [here](http://git.joeyh.name/?p=oldusenet.git;a=summary).
 
 ----
 
diff --git a/blog/entry/cpan_purity_tester.mdwn b/blog/entry/cpan_purity_tester.mdwn
index c94ef79..5c87a73 100644
--- a/blog/entry/cpan_purity_tester.mdwn
+++ b/blog/entry/cpan_purity_tester.mdwn
@@ -1,6 +1,6 @@
 # CPAN Purity tester
 
-<a href="http://git.kitenet.net/?p=joey/home.git;a=blob_plain;f=bin/cpan-purity">Here</a>'s a fairly
+<a href="http://git.joeyh.name/?p=joey/home.git;a=blob_plain;f=bin/cpan-purity">Here</a>'s a fairly
 sweet perl hack that I just wrote. Test how much of a the guts of a program
 comes from sweet, delicious <a href="http://cpan.org/">CPAN</a>, and how
 much is nasty perl code you wrote. 
diff --git a/blog/entry/dadagoogoo.mdwn b/blog/entry/dadagoogoo.mdwn
index 555f4ba..0235e5c 100644
--- a/blog/entry/dadagoogoo.mdwn
+++ b/blog/entry/dadagoogoo.mdwn
@@ -32,8 +32,8 @@ manage some kind of sense at length too:
 
 This was accomplished using only 99 lines of code.
 I imported the datasets into Xapian databases using
-[this program](http://git.kitenet.net/?p=joey/src.git;a=blob;f=misc/googlengrams/populate.pl).
-And [this program](http://git.kitenet.net/?p=joey/src.git;a=blob;f=misc/googlengrams/dadagoogoo.pl) is the text generator.
+[this program](http://git.joeyh.name/?p=joey/src.git;a=blob;f=misc/googlengrams/populate.pl).
+And [this program](http://git.joeyh.name/?p=joey/src.git;a=blob;f=misc/googlengrams/dadagoogoo.pl) is the text generator.
 
 I threw out the metadata, to keep the Xapian databases of reasonable
 size. By which I mean, only a dozen gigabytes. It might be interesting
diff --git a/blog/entry/dbus_reconnection.mdwn b/blog/entry/dbus_reconnection.mdwn
index f8cedc9..8f81124 100644
--- a/blog/entry/dbus_reconnection.mdwn
+++ b/blog/entry/dbus_reconnection.mdwn
@@ -1,7 +1,7 @@
 [Julien](http://blog.technologeek.org/2008/06/07/112), dbus and hal make
 handling server reconnection correctly Hard, or impossible, in my limited
 experience. This information is what I can remember based on 
-[git logs](http://git.kitenet.net/?p=wmbattery.git;a=blobdiff;f=simplehal.c;h=77da060ed3a1377ddeca48acfc9dfbed912b8e9b;hp=f345b9a3995e2b37e6c3c80079311b8fe5a08a60;hb=2b47eca8b1e1c87656f67f1f30f45ef6afface7a;hpb=e48d2d48acbaa547052f2b90e332752445802bd4)
+[git logs](http://git.joeyh.name/?p=wmbattery.git;a=blobdiff;f=simplehal.c;h=77da060ed3a1377ddeca48acfc9dfbed912b8e9b;hp=f345b9a3995e2b37e6c3c80079311b8fe5a08a60;hb=2b47eca8b1e1c87656f67f1f30f45ef6afface7a;hpb=e48d2d48acbaa547052f2b90e332752445802bd4)
 from when I beat my brains against this particular wall for a few days.
 
 You'd think you could check for an exception after calling
diff --git a/blog/entry/fall_back_day.mdwn b/blog/entry/fall_back_day.mdwn
index 3009b1c..84a7c7e 100644
--- a/blog/entry/fall_back_day.mdwn
+++ b/blog/entry/fall_back_day.mdwn
@@ -3,11 +3,11 @@ time, money, and even lives. So instead of pointing to new
 indicators of that, I'll post some daylight related code today, since
 daylight just got very scarce.
 
-[Here's](http://git.kitenet.net/?p=joey/home.git;a=blob;f=bin/sunrise;h=844cde4dc3d8050fc2192548da2da1c49406a6a8;hb=da102bec5ea1fa2ac2c9256d933d2cc16a71dcd2)
+[Here's](http://git.joeyh.name/?p=joey/home.git;a=blob;f=bin/sunrise;h=844cde4dc3d8050fc2192548da2da1c49406a6a8;hb=da102bec5ea1fa2ac2c9256d933d2cc16a71dcd2)
 my old sunrise/sunset program. Install under either name and it'll
 print the time of sunrise or sunset. Implemented as an insane `remind` script.
 
-[Here's](http://git.kitenet.net/?p=joey/home.git;a=blob;f=bin/sunrise;h=2650184ca01d495a4e45bac1a88f923a837d102c;hb=49a58adb36a22c476c5497d5d031eb8725ac3d76)
+[Here's](http://git.joeyh.name/?p=joey/home.git;a=blob;f=bin/sunrise;h=2650184ca01d495a4e45bac1a88f923a837d102c;hb=49a58adb36a22c476c5497d5d031eb8725ac3d76)
 my new version of the same thing, featuring a spiffier output and saner
 implementation:
 
diff --git a/blog/entry/file_set_split_utility.mdwn b/blog/entry/file_set_split_utility.mdwn
index 5189e2a..48e5f8f 100644
--- a/blog/entry/file_set_split_utility.mdwn
+++ b/blog/entry/file_set_split_utility.mdwn
@@ -47,6 +47,6 @@ I'm currently using gafitter, although oddly not using its GA mode, but its
 simple packing mode (because I want to keep subdirs on the same dvd). The
 script I use to split out a dvd worth of stuff with gafitter and burn it
 with growisofs can be downloaded from my repo
-[here](http://git.kitenet.net/?p=joey/home.git;a=blob_plain;f=bin/dvdarchive;hb=HEAD).
+[here](http://git.joeyh.name/?p=joey/home.git;a=blob_plain;f=bin/dvdarchive;hb=HEAD).
 
 [[discussion]]
diff --git a/blog/entry/git_transitions.mdwn b/blog/entry/git_transitions.mdwn
index 3c93d4a..dbc2b3e 100644
--- a/blog/entry/git_transitions.mdwn
+++ b/blog/entry/git_transitions.mdwn
@@ -1,4 +1,4 @@
-I've been moving [some things](http://git.kitenet.net/) to git. My blog is the
+I've been moving [some things](http://git.joeyh.name/) to git. My blog is the
 first thing that really benefitted from distributed revision control though,
 since I can use [[code/ikiwiki]] with git to have a mirror/branch of the blog
 on my laptop. That worked out quite nicely. I've described the setup
diff --git a/blog/entry/haskell_and_xmonad.mdwn b/blog/entry/haskell_and_xmonad.mdwn
index 43617f4..5c60b32 100644
--- a/blog/entry/haskell_and_xmonad.mdwn
+++ b/blog/entry/haskell_and_xmonad.mdwn
@@ -27,7 +27,7 @@ Anyway, I know more than enough Haskell now to configure
 evening, I especially like:
 
 * Being able to compile
-  [my xmonad.hs](http://git.kitenet.net/?p=joey/home-plus.git;a=blob;f=.xmonad/xmonad.hs;hb=HEAD)
+  [my xmonad.hs](http://git.joeyh.name/?p=joey/home-plus.git;a=blob;f=.xmonad/xmonad.hs;hb=HEAD)
   and rely on Haskell's type checking to make sure I wrote it correctly
   and it will work.
 * Xmonad's [integration with gnome](http://www.haskell.org/haskellwiki/Xmonad/Using_xmonad_in_Gnome).
@@ -52,7 +52,7 @@ evening, I especially like:
   </pre>
   (And it wasn't too hard to enhance this with a special-purpose grid
   layout for the workspace I run pidgin on.)
-* That [my xmonad.hs](http://git.kitenet.net/?p=joey/home-plus.git;a=blob;f=.xmonad/xmonad.hs;hb=HEAD)
+* That [my xmonad.hs](http://git.joeyh.name/?p=joey/home-plus.git;a=blob;f=.xmonad/xmonad.hs;hb=HEAD)
   is small, easy to understand, and doesn't contain any
   boilerplate beyond `main = xmonad $ gnomeConfig`.
 * It lets me muck about with doing something real with Haskell without
diff --git a/blog/entry/introducing_mr.mdwn b/blog/entry/introducing_mr.mdwn
index d8bfdf9..059c30d 100644
--- a/blog/entry/introducing_mr.mdwn
+++ b/blog/entry/introducing_mr.mdwn
@@ -30,7 +30,7 @@ directory, but inside the repositories it checks out.
 Here's my current `~/.mrconfig` file.
 
 	[src/mr]
-	checkout = git clone ssh://git.kitenet.net/srv/git/kitenet.net/mr
+	checkout = git clone ssh://git.joeyh.name/srv/git.joeyh.name/mr
 
 	[src/linux-2.6]
 	checkout = git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
@@ -41,7 +41,7 @@ Here's my current `~/.mrconfig` file.
 	# A merge of the upstream dpkg git repo and my own personal branch.
 	checkout = git clone git://git.debian.org/git/dpkg/dpkg.git && \
 	        cd dpkg && \
-	        git remote add kite ssh://kitenet.net/srv/git/kitenet.net/dpkg && \
+	        git remote add kite ssh://kitenet.net/srv/git.joeyh.name/dpkg && \
 	        git fetch kite && \
 	        git checkout -b sourcev3 kite/sourcev3
 	update = git pull origin master && git pull kite sourcev3
diff --git a/blog/entry/introducing_propellor.mdwn b/blog/entry/introducing_propellor.mdwn
index 97f6f28..cb8fd46 100644
--- a/blog/entry/introducing_propellor.mdwn
+++ b/blog/entry/introducing_propellor.mdwn
@@ -15,7 +15,7 @@ debconf, which claims to be the "Debian Configuration Management system"..
 But I didn't understand configuration management back then either.)
 
 So, propellor makes some perhaps wacky choices. The least of these
-is that it's built from [a git repository](http://git.kitenet.net/?p=propellor.git;a=summary)
+is that it's built from [a git repository](http://git.joeyh.name/?p=propellor.git;a=summary)
 that any (theoretical) other users will fork and modify; a cron job can
 re-make it from time to time and pull down configuration changes, or
 *something* can be run to push changes.
diff --git a/blog/entry/linux_radio_recorder.mdwn b/blog/entry/linux_radio_recorder.mdwn
index a9913d2..27e55f7 100644
--- a/blog/entry/linux_radio_recorder.mdwn
+++ b/blog/entry/linux_radio_recorder.mdwn
@@ -2,10 +2,10 @@ I dug up an old radio and threw this together tonight. It's been done
 before, but the scripts out there seemed overly complex and didn't use
 alsa. Here's how I did it:
 
-* [radiorecord](http://git.kitenet.net/?p=joey/home.git;a=blob_plain;f=bin/radiorecord;hb=HEAD)
+* [radiorecord](http://git.joeyh.name/?p=joey/home.git;a=blob_plain;f=bin/radiorecord;hb=HEAD)
   is a shell script to record a given number of minutes from
   the radio to an ogg file.
-* [crontab](http://git.kitenet.net/?p=joey/cron.git;a=blob_plain;f=joey/dragon.kitenet.net;hb=HEAD)
+* [crontab](http://git.joeyh.name/?p=joey/cron.git;a=blob_plain;f=joey/dragon.kitenet.net;hb=HEAD)
   to schedule when to record shows
 
 Of course, this assumes that the station doesn't move shows around and that
diff --git a/blog/entry/local_rsync_accelerator.mdwn b/blog/entry/local_rsync_accelerator.mdwn
index 78e3cb3..d0685a4 100644
--- a/blog/entry/local_rsync_accelerator.mdwn
+++ b/blog/entry/local_rsync_accelerator.mdwn
@@ -33,7 +33,7 @@ on a typical home NAS, with a slow (arm) CPU, the picture changes
 entirely -- now the checksum overhead is unbearable, while the IO overhead
 is minimal.
 
-So, [here's local-rsync](http://git.kitenet.net/?p=joey/home.git;a=blob;f=bin/local-rsync;hb=0bed147834aef4efe8650d731f9160fb41b16014).

(Diff truncated)
diff --git a/code/moreutils/discussion.mdwn b/code/moreutils/discussion.mdwn
index b229326..c6766eb 100644
--- a/code/moreutils/discussion.mdwn
+++ b/code/moreutils/discussion.mdwn
@@ -68,6 +68,8 @@ I think this would be usefull as hell for debuging cron scripts. I have currentl
 > I think this would be a reasonable default behavior. Patches accepted.
 > --[[Joey]] 
 
+>> I just realized that this would be usefull as separate wrapper tool that can be used by chronic. --Tomas Mudrunka
+
 ## poptail and peeif
 
 I just finished two utilities that might be general purpose enough for the collection.  They're on github here:

diff --git a/code/moreutils/discussion.mdwn b/code/moreutils/discussion.mdwn
index e2d642d..b229326 100644
--- a/code/moreutils/discussion.mdwn
+++ b/code/moreutils/discussion.mdwn
@@ -39,6 +39,8 @@ I'd would really appreciate this feature. I am trying to write my scripts to ret
 > don't exit nonzero on error are somehow practicing good hygene in their
 > output to stderr. --[[Joey]]
 
+>> In fact such scripts do not usually output to stderr themselves. But they may just call some (well written) binararies that output to stderr or exit nonzero. However the script itself exits zero after such fail, because it didn't expected binary to fail and it's not handler properly. At least i think this is the case. --Tomas Mudrunka
+
 ### verbose mode for distidguishing output streams and return code
 
 Another feature that might be interresting in chronic would be distinguishing between stdout and stderr in output.

update
diff --git a/code/moreutils.mdwn b/code/moreutils.mdwn
index b7cd109..d02a7a5 100644
--- a/code/moreutils.mdwn
+++ b/code/moreutils.mdwn
@@ -32,6 +32,7 @@ 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
+- errno: look up errno names and descriptions
 - ifdata: get network interface info without parsing ifconfig output
 - ifne: run a program if the standard input is not empty
 - isutf8: check if a file or standard input is utf-8
diff --git a/code/moreutils/discussion.mdwn b/code/moreutils/discussion.mdwn
index ceba4c1..e2d642d 100644
--- a/code/moreutils/discussion.mdwn
+++ b/code/moreutils/discussion.mdwn
@@ -30,6 +30,15 @@ I'd would really appreciate this feature. I am trying to write my scripts to ret
 
 -- Tomas Mudrunka
 
+> I'd proabably be willing to merge a patch adding -e, but making it the
+> default would break existing uses of chronic.
+> 
+> I don't like the filtering out whitespace idea.
+> 
+> I'm somewhat dubious about the idea that scripts so badly written they
+> don't exit nonzero on error are somehow practicing good hygene in their
+> output to stderr. --[[Joey]]
+
 ### verbose mode for distidguishing output streams and return code
 
 Another feature that might be interresting in chronic would be distinguishing between stdout and stderr in output.
@@ -54,6 +63,9 @@ I think this would be usefull as hell for debuging cron scripts. I have currentl
 
 -- Tomas Mudrunka
 
+> I think this would be a reasonable default behavior. Patches accepted.
+> --[[Joey]] 
+
 ## poptail and peeif
 
 I just finished two utilities that might be general purpose enough for the collection.  They're on github here:
@@ -74,6 +86,8 @@ How about giving errno program some more love and just mentioning it on the proj
 
 Thanks
 
+> Thanks, done --[[Joey]]
+
 ## dc
 
 You are sick of doing ls | wc -l
@@ -175,7 +189,7 @@ tree using ansi colors and the md5sum if it is a file <= 100 MB.
     -r-x ug- 20120322-1859 /usr/bin/X a7ac83a4031da58dab3a88e9dd247f51
 
 It needs ruby. Tested & developed under Ubuntu 12.04 with Ruby 1.8.
-
+ 
 License GPLv3.
 
 I would be glad if you embed it into moreutils. Please send a note if you are interested.

move some things out of the propellor feed
diff --git a/blog/entry/how_I_wrote_init_by_accident.mdwn b/blog/entry/how_I_wrote_init_by_accident.mdwn
index 946a2ac..ba21253 100644
--- a/blog/entry/how_I_wrote_init_by_accident.mdwn
+++ b/blog/entry/how_I_wrote_init_by_accident.mdwn
@@ -53,5 +53,5 @@ If that does happen, perhaps I'll eventually be able to remove 2 lines of code
 from propellor.
 
 [[!meta title="how I wrote init by accident"]]
-[[!tag propellor]]
+[[!tag code/propellor]]
 [[!tag haskell]]
diff --git a/blog/entry/then_and_now.mdwn b/blog/entry/then_and_now.mdwn
index 597b7e7..242d684 100644
--- a/blog/entry/then_and_now.mdwn
+++ b/blog/entry/then_and_now.mdwn
@@ -62,4 +62,4 @@ of code, [[propellor_is_d-i_2.0]]); indeed I'm just adding generic useful stuff
 and building further stuff out of it without any particular end goal. Perhaps
 that's the real difference.
 
-[[!tag propellor]]
+[[!tag code/propellor]]
diff --git a/blog/entry/using_a_debian_package_as_the_remote_for_a_local_config_repo.mdwn b/blog/entry/using_a_debian_package_as_the_remote_for_a_local_config_repo.mdwn
index 1e4ed59..4c02901 100644
--- a/blog/entry/using_a_debian_package_as_the_remote_for_a_local_config_repo.mdwn
+++ b/blog/entry/using_a_debian_package_as_the_remote_for_a_local_config_repo.mdwn
@@ -76,4 +76,4 @@ somewhere in /usr, and check them into a new empty repository as part of the
 generation of the upstream/master branch.
 
 [[!meta title="using a debian package as the remote for a local config repo"]]
-[[!tag propellor]]
+[[!tag code/propellor]]

fix tag
diff --git a/blog/entry/type_safe_multi-OS_Propellor.mdwn b/blog/entry/type_safe_multi-OS_Propellor.mdwn
index f211610..fce26bb 100644
--- a/blog/entry/type_safe_multi-OS_Propellor.mdwn
+++ b/blog/entry/type_safe_multi-OS_Propellor.mdwn
@@ -190,4 +190,4 @@ system questions.
 Also thanks to the Shuttleworth foundation, which funded this work
 by way of a Flash Grant.
 
-[[!tag code/propellor haskell]]
+[[!tag propellor haskell]]

tyo
diff --git a/blog/entry/type_safe_multi-OS_Propellor.mdwn b/blog/entry/type_safe_multi-OS_Propellor.mdwn
index c3d9ae6..f211610 100644
--- a/blog/entry/type_safe_multi-OS_Propellor.mdwn
+++ b/blog/entry/type_safe_multi-OS_Propellor.mdwn
@@ -93,7 +93,7 @@ aptUpgraded = property "apt upgraded" (apt "upgrade" `requires` apt "update")
 pkgUpgraded :: Property FreeBSD
 pkgUpgraded = property "pkg upgraded" (pkg "upgrade")
 	
-upgraded :: UnixLike
+upgraded :: Property UnixLike
 upgraded = (aptUpgraded `pickOS` pkgUpgraded)
 	`describe` "OS upgraded"
 """]]

layout
diff --git a/blog/entry/type_safe_multi-OS_Propellor.mdwn b/blog/entry/type_safe_multi-OS_Propellor.mdwn
index cad4ee0..c3d9ae6 100644
--- a/blog/entry/type_safe_multi-OS_Propellor.mdwn
+++ b/blog/entry/type_safe_multi-OS_Propellor.mdwn
@@ -8,11 +8,10 @@ the type checker should tell them they're asking for something that can't
 fly.
 
 [[!format haskell """
-	-- Is this a Debian or a FreeBSD host? I can't remember, let's
-	-- use both package managers!
-	host "example.com" $ props
-		& aptUpgraded
-		& pkgUpgraded
+-- Is this a Debian or a FreeBSD host? I can't remember, let's use both package managers!
+host "example.com" $ props
+	& aptUpgraded
+	& pkgUpgraded
 """]]
 
 As of propellor 3.0.0 ([in git now](http://source.propellor.branchable.com/?p=source.git;a=commitdiff;h=a1655d24bbb1db9caccdf93eae8110d746389ae2);
@@ -21,7 +20,9 @@ to be released soon), the type checker will catch such mistakes.
 Also, it's really easy to combine two OS-specific properties into a
 property that supports both OS's:
 
-	upgraded = aptUpgraded `pickOS` pkgUpgraded
+[[!format haskell """
+upgraded = aptUpgraded `pickOS` pkgUpgraded
+"""]]
 
 ### type level lists and functions
 
@@ -31,9 +32,9 @@ types describing the type, and I couldn't find a better name.) This list
 can contain one or more OS's targeted by the property:
 
 [[!format haskell """
-	aptUpgraded :: Property (MetaTypes '[ 'Targeting 'OSDebian, 'Targeting 'OSBuntish ])
+aptUpgraded :: Property (MetaTypes '[ 'Targeting 'OSDebian, 'Targeting 'OSBuntish ])
 
-	pkgUpgraded :: Property (MetaTypes '[ 'Targeting 'OSFreeBSD ])
+pkgUpgraded :: Property (MetaTypes '[ 'Targeting 'OSFreeBSD ])
 """]]
 
 In Haskell type-level lists and other DataKinds are indicated by the
@@ -42,9 +43,9 @@ aliases and type operators, which let the same types be expressed
 more cleanly:
 
 [[!format haskell """
-	aptUpgraded :: Property (Debian + Buntish)
+aptUpgraded :: Property (Debian + Buntish)
 
-	pkgUpgraded :: Property FreeBSD
+pkgUpgraded :: Property FreeBSD
 """]]
 
 Whenever two properties are combined, their metatypes are combined
@@ -86,15 +87,15 @@ As shown here, `pickOS` makes a property that
 decides which of two properties to use based on the host's OS.
 
 [[!format haskell """
-	aptUpgraded :: Property DebianLike
-	aptUpgraded = property "apt upgraded" (apt "upgrade" `requires` apt "update")
+aptUpgraded :: Property DebianLike
+aptUpgraded = property "apt upgraded" (apt "upgrade" `requires` apt "update")
 
-	pkgUpgraded :: Property FreeBSD
-	pkgUpgraded = property "pkg upgraded" (pkg "upgrade")
+pkgUpgraded :: Property FreeBSD
+pkgUpgraded = property "pkg upgraded" (pkg "upgrade")
 	
-	upgraded :: UnixLike
-	upgraded = (aptUpgraded `pickOS` pkgUpgraded)
-		`describe` "OS upgraded"
+upgraded :: UnixLike
+upgraded = (aptUpgraded `pickOS` pkgUpgraded)
+	`describe` "OS upgraded"
 """]]
 
 Any number of OS's can be chained this way, to build a property that
@@ -133,11 +134,11 @@ figure out all the types without some help.
 A simple example of this problem is as follows.
 
 [[!format haskell """
-	foo :: Property UnixLike
-	foo = p `requires` bar
-	  where
-		p = property "foo" $ do
-			...
+foo :: Property UnixLike
+foo = p `requires` bar
+  where
+	p = property "foo" $ do
+		...
 """]]
  
 The type checker will complain that "The type variable ‘metatypes1’ is
@@ -162,9 +163,11 @@ hackage, it still seems to
 Also, using `ensureProperty`, which runs one property inside the action
 of another property, got complicated by the need to pass it a type witness.
 
-	foo = Property Debian
-	foo = property' $ \witness -> do
-		ensureProperty witness (aptInstall "foo")
+[[!format haskell """
+foo = Property Debian
+foo = property' $ \witness -> do
+	ensureProperty witness (aptInstall "foo")
+"""]]
 
 That witness is used to type check that the inner property targets
 every OS that the outer property targets. I think it might be possible

publish
diff --git a/blog/entry/type_safe_multi-OS_Propellor.mdwn b/blog/entry/type_safe_multi-OS_Propellor.mdwn
index c96f7a9..cad4ee0 100644
--- a/blog/entry/type_safe_multi-OS_Propellor.mdwn
+++ b/blog/entry/type_safe_multi-OS_Propellor.mdwn
@@ -5,7 +5,7 @@ FreeBSD, and others on both.
 
 The user shouldn't need to worry about making a mistake like this;
 the type checker should tell them they're asking for something that can't
-work.
+fly.
 
 [[!format haskell """
 	-- Is this a Debian or a FreeBSD host? I can't remember, let's
@@ -15,12 +15,17 @@ work.
 		& pkgUpgraded
 """]]
 
-As of propellor 3.0.0 (to be released soon; in git now), that will fail to
-build.
+As of propellor 3.0.0 ([in git now](http://source.propellor.branchable.com/?p=source.git;a=commitdiff;h=a1655d24bbb1db9caccdf93eae8110d746389ae2);
+to be released soon), the type checker will catch such mistakes.
+
+Also, it's really easy to combine two OS-specific properties into a
+property that supports both OS's:
+
+	upgraded = aptUpgraded `pickOS` pkgUpgraded
 
 ### type level lists and functions
 
-To make that fail to build, I used type-level lists. A property has a
+The magick making this work is type-level lists. A property has a
 metatypes list as part of its type. (So called because it's additional
 types describing the type, and I couldn't find a better name.) This list
 can contain one or more OS's targeted by the property:
@@ -47,8 +52,8 @@ using a type-level function. Combining `aptUpgraded` and `pkgUpgraded`
 will yield a metatypes that targets no OS's, since they have none in
 common. So will fail to type check.
 
-My implementation of the metatypes lists is over 200 lines of code that
-consists entirely of types and type families. It includes a basic
+My implementation of the metatypes lists is hundreds of lines of
+code, consisting entirely of types and type families. It includes a basic
 implementation of singletons, and is portable back to ghc 7.6 to support
 Debian stable. While it takes some contortions to support such an old
 version of ghc, it's pretty awesome that the ghc in Debian stable supports
@@ -86,7 +91,7 @@ decides which of two properties to use based on the host's OS.
 
 	pkgUpgraded :: Property FreeBSD
 	pkgUpgraded = property "pkg upgraded" (pkg "upgrade")
-
+	
 	upgraded :: UnixLike
 	upgraded = (aptUpgraded `pickOS` pkgUpgraded)
 		`describe` "OS upgraded"
@@ -173,11 +178,13 @@ I know most readers stop reading at "monad". So, I'll stop writing. ;)
 
 ### thanks
 
-Thanks to David Miani who answered my first tentative question that led
-down this path, with a big hunk of code.
+Thanks to David Miani who answered my first tentative question with
+a big hunk of example code that got me on the right track.
 
 Also to many other people who answered increasingly esoteric Haskell type
 system questions.
 
 Also thanks to the Shuttleworth foundation, which funded this work
 by way of a Flash Grant.
+
+[[!tag code/propellor haskell]]

blog update
diff --git a/blog/entry/type_safe_multi-OS_Propellor.mdwn b/blog/entry/type_safe_multi-OS_Propellor.mdwn
new file mode 100644
index 0000000..c96f7a9
--- /dev/null
+++ b/blog/entry/type_safe_multi-OS_Propellor.mdwn
@@ -0,0 +1,183 @@
+Propellor was recently ported to FreeBSD, by Evan Cofsky. This new feature
+led me down a two week long rabbit hole to make it type safe. In particular,
+Propellor needed to be taught that some properties work on Debian, others on
+FreeBSD, and others on both.
+
+The user shouldn't need to worry about making a mistake like this;
+the type checker should tell them they're asking for something that can't
+work.
+
+[[!format haskell """
+	-- Is this a Debian or a FreeBSD host? I can't remember, let's
+	-- use both package managers!
+	host "example.com" $ props
+		& aptUpgraded
+		& pkgUpgraded
+"""]]
+
+As of propellor 3.0.0 (to be released soon; in git now), that will fail to
+build.
+
+### type level lists and functions
+
+To make that fail to build, I used type-level lists. A property has a
+metatypes list as part of its type. (So called because it's additional
+types describing the type, and I couldn't find a better name.) This list
+can contain one or more OS's targeted by the property:
+
+[[!format haskell """
+	aptUpgraded :: Property (MetaTypes '[ 'Targeting 'OSDebian, 'Targeting 'OSBuntish ])
+
+	pkgUpgraded :: Property (MetaTypes '[ 'Targeting 'OSFreeBSD ])
+"""]]
+
+In Haskell type-level lists and other DataKinds are indicated by the
+`'` if you have not seen that before. There are some convenience
+aliases and type operators, which let the same types be expressed
+more cleanly:
+
+[[!format haskell """
+	aptUpgraded :: Property (Debian + Buntish)
+
+	pkgUpgraded :: Property FreeBSD
+"""]]
+
+Whenever two properties are combined, their metatypes are combined
+using a type-level function. Combining `aptUpgraded` and `pkgUpgraded`
+will yield a metatypes that targets no OS's, since they have none in
+common. So will fail to type check.
+
+My implementation of the metatypes lists is over 200 lines of code that
+consists entirely of types and type families. It includes a basic
+implementation of singletons, and is portable back to ghc 7.6 to support
+Debian stable. While it takes some contortions to support such an old
+version of ghc, it's pretty awesome that the ghc in Debian stable supports
+this stuff.
+
+### extending beyond targeted OS's
+
+Before this change, Propellor's Property type had already been slightly
+refined, tagging them with `HasInfo` or `NoInfo`, as described
+in [[making_propellor_safer_with_GADTs_and_type_families]]. I needed to
+keep that `HasInfo` in the type of properties.
+
+But, it seemed unnecessary verbose to have types like `Property NoInfo Debian`.
+Especially if I want to add even more information to Property
+types later. `Property NoInfo Debian NoPortsOpen` would be a real mouthful to
+need to write for every property.
+
+Luckily I now have this handy type-level list. So, I can shove more
+types into it, so `Property (HasInfo + Debian)` is used where necessary,
+and `Property Debian` can be used everywhere else.
+
+Since I can add more types to the type-level list, without affecting
+other properties, I expect to be able to implement type-level port
+conflict detection next. Should be fairly easy to do without changing
+the API except for properties that use ports.
+
+### singletons
+
+As shown here, `pickOS` makes a property that 
+decides which of two properties to use based on the host's OS.
+
+[[!format haskell """
+	aptUpgraded :: Property DebianLike
+	aptUpgraded = property "apt upgraded" (apt "upgrade" `requires` apt "update")
+
+	pkgUpgraded :: Property FreeBSD
+	pkgUpgraded = property "pkg upgraded" (pkg "upgrade")
+
+	upgraded :: UnixLike
+	upgraded = (aptUpgraded `pickOS` pkgUpgraded)
+		`describe` "OS upgraded"
+"""]]
+
+Any number of OS's can be chained this way, to build a property that
+is super-portable out of simple little non-portable properties.
+This is a sweet combinator!
+
+Singletons are types that are inhabited by a single value.
+This lets the value be inferred from the type, which came in handy
+in building the `pickOS` property combinator.
+
+Its implementation needs to be able to look at each of the properties at
+runtime, to compare the OS's they target with the actial OS of the host.
+That's done by stashing a target list value inside a property. The target
+list value is inferred from the type of the property, thanks to singletons,
+and so does not need to be passed in to `property`. That saves
+keyboard time and avoids mistakes.
+
+### is it worth it?
+
+It's important to consider whether more complicated types are a net
+benefit. Of course, opinions vary widely on that question in general!
+But let's consider it in light of my main goals for Propellor:
+
+1. Help save the user from pushing a broken configuration to their machines
+   at a time when they're down in the trenches dealing with some urgent
+   problem at 3 am.
+2. Advance the state of the art in configuration management by
+   taking advantage of the state of the art in strongly typed haskell.
+
+This change definitely meets both criteria. But there is a tradeoff;
+it got a little bit harder to write new propellor properties. Not only do
+new properties need to have their type set to target appropriate systems,
+but the more polymorphic code is, the more likely the type checker can't
+figure out all the types without some help.
+
+A simple example of this problem is as follows.
+
+[[!format haskell """
+	foo :: Property UnixLike
+	foo = p `requires` bar
+	  where
+		p = property "foo" $ do
+			...
+"""]]
+ 
+The type checker will complain that "The type variable ‘metatypes1’ is
+ambiguous". Problem is that it can't infer the type of `p` because many
+different types could be combined with the `bar` property and all would
+yield a `Property UnixLike`. The solution is simply to add a type signature
+like `p :: Property UnixLike`
+
+Since this only affects creating new properties, and not combining existing
+properties (which have known types), it seems like a reasonable tradeoff.
+
+### things to improve later
+
+There are a few warts that I'm willing to live with for now...
+
+Currently, `Property (HasInfo + Debian)` is different than `Property (Debian +
+HasInfo)`, but they should really be considered to be the same type. That is, I
+need type-level sets, not lists. While there's a type level sets library for
+hackage, it still seems to 
+[require a specific order of the set items when writing down a type signature](https://github.com/dorchard/type-level-sets/issues/5).
+
+Also, using `ensureProperty`, which runs one property inside the action
+of another property, got complicated by the need to pass it a type witness.
+
+	foo = Property Debian
+	foo = property' $ \witness -> do
+		ensureProperty witness (aptInstall "foo")
+
+That witness is used to type check that the inner property targets
+every OS that the outer property targets. I think it might be possible
+to store the witness in the monad, and have ensureProperty read it, but
+it might complicate the type of the monad too much, since it would
+have to be parameterized on the type of the witness.
+
+Oh no, I mentioned monads. While type level lists and type functions and
+generally bending the type checker to my will is all well and good,
+I know most readers stop reading at "monad". So, I'll stop writing. ;)
+
+### thanks
+
+Thanks to David Miani who answered my first tentative question that led
+down this path, with a big hunk of code.
+
+Also to many other people who answered increasingly esoteric Haskell type
+system questions.
+
+Also thanks to the Shuttleworth foundation, which funded this work
+by way of a Flash Grant.

diff --git a/code/moreutils/discussion.mdwn b/code/moreutils/discussion.mdwn
index 3ffb4ba..ceba4c1 100644
--- a/code/moreutils/discussion.mdwn
+++ b/code/moreutils/discussion.mdwn
@@ -26,7 +26,7 @@ I am not sure, but this probably should not trigger if stderr contains only whit
 
 Also maybe you can just make this default and use -e to disable it and do the legacy behavior, it's up to you.
 
-I'd would really appreciate this feature. I am trying to write my scripts to return proper code, however i often use 3rd party scripts without proper exit codes and i can't or don't want to change them.
+I'd would really appreciate this feature. I am trying to write my scripts to return proper code, however i often use 3rd party scripts without proper exit codes and i can't or don't want to change them. Such scripts usualy output lots of stdout when everything is OK, but only way to tell that something went wrong is when they output something to stderr. That would be my usecase.
 
 -- Tomas Mudrunka
 

Feature proposals for chronic
diff --git a/code/moreutils/discussion.mdwn b/code/moreutils/discussion.mdwn
index d98c4ee..3ffb4ba 100644
--- a/code/moreutils/discussion.mdwn
+++ b/code/moreutils/discussion.mdwn
@@ -1,6 +1,59 @@
 Feel free to edit this page to suggest tools to add, or make any other
 comments --[[Joey]]
 
+## chronic
+
+### triggering by non-empty stderr output
+
+chronic is now triggered by program returning nonzero exit code. however it's quite often that i encounter scripts that don't return error exit code, but they still output errors on stderr.
+
+I'd like to have chronic to be able to setup in way that would trigger output by nonzero output to stderr.
+
+I suggest parameter -e to do this. (e stands for error)
+
+Like:
+
+    chronic bash -c 'ls /nonexistent_file; echo hello; exit 0' #no output
+    chronic -e bash -c 'ls /nonexistent_file; echo hello; exit 0' #output
+
+You may say that i could simply do
+
+    bash -c 'ls /nonexistent_file; echo hello; exit 0' > /dev/null
+
+to achieve the same, but it's not the case as it does throw the stdout away. i'd like to see nothing if there's no stderr and exit code 0. if there's non-zero exit code or stderr then i want to see both. stdout and stderr.
+
+I am not sure, but this probably should not trigger if stderr contains only whitespace characters. It should need at least one printable.
+
+Also maybe you can just make this default and use -e to disable it and do the legacy behavior, it's up to you.
+
+I'd would really appreciate this feature. I am trying to write my scripts to return proper code, however i often use 3rd party scripts without proper exit codes and i can't or don't want to change them.
+
+-- Tomas Mudrunka
+
+### verbose mode for distidguishing output streams and return code
+
+Another feature that might be interresting in chronic would be distinguishing between stdout and stderr in output.
+I suggest -v as verbose
+
+    chronic bash -c 'echo foo 1>&2; echo -n bar; echo baz 1>&2; exit 23' #outputs:
+    foo
+    barbaz
+
+    chronic -v bash -c 'echo foo 1>&2; echo -n bar; echo baz 1>&2; exit 23' #outputs:
+    E: foo
+    O: bar
+    E: baz
+    R: 23
+
+Also note it adds newline to output when output stream changes in middle of line. Just to make sure that "E: " or "O: " is at the beginning of line.
+E: identifies stderr output, O: identifies standart output and R: identifies return code.
+
+This should also work in combination with proposed -e, like chronic -ve something...
+
+I think this would be usefull as hell for debuging cron scripts. I have currently troubles with such debugging.
+
+-- Tomas Mudrunka
+
 ## poptail and peeif
 
 I just finished two utilities that might be general purpose enough for the collection.  They're on github here:

add news item for github-backup 1.20160319
diff --git a/code/github-backup/news/version_1.20141222.mdwn b/code/github-backup/news/version_1.20141222.mdwn
deleted file mode 100644
index b429657..0000000
--- a/code/github-backup/news/version_1.20141222.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-github-backup 1.20141222 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Added gitriddance(1), a utility to close all issues and pull requests,
-     for repos that don't want to be bothered with GitHub's proprietary
-     issue tracker.
-   * gitriddance depends on github 0.13.1, which has bug fixes
-     for posting comments.
-   * Various updates to internal git and utility libraries shared with git-annex."""]]
\ No newline at end of file
diff --git a/code/github-backup/news/version_1.20160319.mdwn b/code/github-backup/news/version_1.20160319.mdwn
new file mode 100644
index 0000000..ca3efaf
--- /dev/null
+++ b/code/github-backup/news/version_1.20160319.mdwn
@@ -0,0 +1,6 @@
+github-backup 1.20160319 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Update to github-0.14.1.
+     Building with old versions is not supported due to the massive API
+     changes in this version of the github library.
+   * Added support for oath tokens."""]]
\ No newline at end of file

update
diff --git a/trips/2016/boston.mdwn b/trips/2016/boston.mdwn
index 6f827a7..5e40ebb 100644
--- a/trips/2016/boston.mdwn
+++ b/trips/2016/boston.mdwn
@@ -1,7 +1,7 @@
 I'm visiting Boston, 16-20 March. 
 
 * Match 16th [Boston Haskell](http://www.meetup.com/Boston-Haskell/)
-* Match 17th afternoon hin a coffee house, dinner at [Asmara](http://www.asmararestaurantboston.com/) 5pm
+* Match 17th afternoon in a coffee house, dinner at [Asmara](http://www.asmararestaurantboston.com/) 5pm, [Anne Leckie book signing](http://www.pandemoniumbooks.com/event/ann-leckie-author-event)/board gaming 7 pm
 * March 18th [SpinachCon](https://libreplanet.org/wiki/Event:LibrePlanet/LibrePlanet/3-18-2016_-Event_1)
 * March 18th Free Software Foundation open house at their offices, ~6pm
 * March 19th-20th [LibrePlanet](https://www.libreplanet.org/2016/)

typoski
diff --git a/trips/2016/boston.mdwn b/trips/2016/boston.mdwn
index 28a8128..6f827a7 100644
--- a/trips/2016/boston.mdwn
+++ b/trips/2016/boston.mdwn
@@ -3,7 +3,7 @@ I'm visiting Boston, 16-20 March.
 * Match 16th [Boston Haskell](http://www.meetup.com/Boston-Haskell/)
 * Match 17th afternoon hin a coffee house, dinner at [Asmara](http://www.asmararestaurantboston.com/) 5pm
 * March 18th [SpinachCon](https://libreplanet.org/wiki/Event:LibrePlanet/LibrePlanet/3-18-2016_-Event_1)
-* March 18th Free Softeware open house at their offices, ~6pm
+* March 18th Free Software Foundation open house at their offices, ~6pm
 * March 19th-20th [LibrePlanet](https://www.libreplanet.org/2016/)
 
 Would be pleased to get together with friends, users of my software, etc at

add
diff --git a/trips/2016/boston.mdwn b/trips/2016/boston.mdwn
new file mode 100644
index 0000000..28a8128
--- /dev/null
+++ b/trips/2016/boston.mdwn
@@ -0,0 +1,10 @@
+I'm visiting Boston, 16-20 March. 
+
+* Match 16th [Boston Haskell](http://www.meetup.com/Boston-Haskell/)
+* Match 17th afternoon hin a coffee house, dinner at [Asmara](http://www.asmararestaurantboston.com/) 5pm
+* March 18th [SpinachCon](https://libreplanet.org/wiki/Event:LibrePlanet/LibrePlanet/3-18-2016_-Event_1)
+* March 18th Free Softeware open house at their offices, ~6pm
+* March 19th-20th [LibrePlanet](https://www.libreplanet.org/2016/)
+
+Would be pleased to get together with friends, users of my software, etc at
+any of these times. Say Hi when you see me, or shoot me an email.

scroll servers working again
diff --git a/code/scroll.mdwn b/code/scroll.mdwn
index 08e5eb1..9741937 100644
--- a/code/scroll.mdwn
+++ b/code/scroll.mdwn
@@ -10,7 +10,6 @@ challenge. It is written in Haskell.
 
 BTW, `scroll` is also a functional unix file pager, like `less` or `more`.
 
-<!-- 
 ## play `scroll`
 
 For a quick play on the web, there are two demo servers up!
@@ -20,7 +19,6 @@ For a quick play on the web, there are two demo servers up!
 
 For deeper exploration, I recommend using telnet instead. Login and
 password for telnet are both "scroll".
--->
 
 ## install `scroll`
 

jetring new maintainer
diff --git a/code.mdwn b/code.mdwn
index be531de..4f13c93 100644
--- a/code.mdwn
+++ b/code.mdwn
@@ -45,6 +45,7 @@ people have taken them on.
 [[devscripts]]
 [[pentium-builder]]
 [[apt-src]]
+[[jetring]]
 
 These need new maintainers, stat!
 
@@ -52,7 +53,6 @@ These need new maintainers, stat!
 [[sleepd]]
 [[pristine-tar]]
 [[alien]]
-[[jetring]]
 [[nslu2-utils]]
 [[ticker]]
 

response
diff --git a/blog/entry/letsencrypt_support_in_propellor/comment_3_86c4651e907e40c41458377e1c99dfbd._comment b/blog/entry/letsencrypt_support_in_propellor/comment_3_86c4651e907e40c41458377e1c99dfbd._comment
new file mode 100644
index 0000000..7cb6ec6
--- /dev/null
+++ b/blog/entry/letsencrypt_support_in_propellor/comment_3_86c4651e907e40c41458377e1c99dfbd._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-03-02T17:16:51Z"
+ content="""
+There's a more generalized property to add additional domains.
+
+	letsEncrypt' :: AgreeTOS -> Domain -> [Domain] -> WebRoot -> Property NoInfo
+"""]]

Added a comment: Multiple domains?
diff --git a/blog/entry/letsencrypt_support_in_propellor/comment_2_64d4fd22bdbcf4e7328fafd0dc23ffc3._comment b/blog/entry/letsencrypt_support_in_propellor/comment_2_64d4fd22bdbcf4e7328fafd0dc23ffc3._comment
new file mode 100644
index 0000000..c8585a8
--- /dev/null
+++ b/blog/entry/letsencrypt_support_in_propellor/comment_2_64d4fd22bdbcf4e7328fafd0dc23ffc3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="NicolasPouillard"
+ subject="Multiple domains?"
+ date="2016-03-02T16:14:19Z"
+ content="""
+I'm glad to see the support of letsencrypt into propellor, so far I've rolled my own scripts calling the docker image...
+
+What about having support for multiple domains?
+"""]]

Added a comment: staging environment
diff --git a/blog/entry/letsencrypt_support_in_propellor/comment_1_888380c796ccb5fbc093cf984b89320e._comment b/blog/entry/letsencrypt_support_in_propellor/comment_1_888380c796ccb5fbc093cf984b89320e._comment
new file mode 100644
index 0000000..c696c03
--- /dev/null
+++ b/blog/entry/letsencrypt_support_in_propellor/comment_1_888380c796ccb5fbc093cf984b89320e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mithrandi@311efa1b2b5c4999c2edae7da06fb825899e8a82"
+ nickname="mithrandi"
+ subject="staging environment"
+ date="2016-03-02T06:19:09Z"
+ content="""
+You can use the Let's Encrypt staging environment for testing; it generates certificates signed by a different untrusted CA, so they're not usable \"for real\", but you don't have to deal with the extreme rate limits the main environment imposes. I think use of the staging environment can be activated by passing \"--staging\" to the main client.
+"""]]

Added a comment: Documentation driven development
diff --git a/blog/entry/documentation_first/comment_1_1c4e9b6fdac008e8eafd813da145baa9._comment b/blog/entry/documentation_first/comment_1_1c4e9b6fdac008e8eafd813da145baa9._comment
new file mode 100644
index 0000000..fb0a885
--- /dev/null
+++ b/blog/entry/documentation_first/comment_1_1c4e9b6fdac008e8eafd813da145baa9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://fanf.livejournal.com/"
+ subject="Documentation driven development"
+ date="2016-02-27T19:19:28Z"
+ content="""
+I often work in a similar way for similar reasons. I have seen it called \"documentation driven development\" by analogy with test driven development.
+
+I have also found that when I don't write the documentation first, I often find when writing it that the code is stupid in one way or another and needs fixing so that the documentation makes sense.
+"""]]

format
diff --git a/blog/entry/documentation_first.mdwn b/blog/entry/documentation_first.mdwn
index 52eb995..41a1467 100644
--- a/blog/entry/documentation_first.mdwn
+++ b/blog/entry/documentation_first.mdwn
@@ -1,5 +1,5 @@
 I write documentation first and code second. I've mentioned this from time
-to time ([[previously|on_not_coding_late]]),
+to time ([[previously|on_not_coding_late]],
 [[previously|screencasts/git-annex_coding_in_haskell]]) but a reader
 pointed out that I've never really explained why I work that way.
 
@@ -28,7 +28,7 @@ down than I did when I started. Hopefully you do too.
 
 [1] I'll often write a bug report down even if I have found the bug myself
     and am going to fix it myself on the same day.
-    [example](http://git-annex.branchable.com/bugs/checksum_loads_whole_file_into_memory/) 
+    ([example](http://git-annex.branchable.com/bugs/checksum_loads_whole_file_into_memory/))
     This is one place where it's
     nice to have bug reports as files in the same repository as the code,
     so that the bug report can be included in the commit fixing it. Often

blog update
diff --git a/blog/entry/documentation_first.mdwn b/blog/entry/documentation_first.mdwn
new file mode 100644
index 0000000..52eb995
--- /dev/null
+++ b/blog/entry/documentation_first.mdwn
@@ -0,0 +1,40 @@
+I write documentation first and code second. I've mentioned this from time
+to time ([[previously|on_not_coding_late]]),
+[[previously|screencasts/git-annex_coding_in_haskell]]) but a reader
+pointed out that I've never really explained why I work that way.
+
+It's a way to make my thinking more concrete without diving all the way
+into the complexities of the code right away. So sometimes, what I write
+down is design documentation, and sometimes it's notes on a bug report[1],
+but if what I'm working on is user-visible, I start by writing down the end
+user documentation.
+
+Writing things down lets me interact with them as words on a page, which
+are more concrete than muddled thoughts in the head, and much easier to
+edit and reason about. Code constrains to existing structures; a blank page
+frees you to explore and build up new ideas. It's the essay writing
+process, applied to software development, with a side effect of making sure
+everything is documented.
+
+Also, end-user documentation is best when it doesn't assume that the user
+has any prior knowledge. The point in time when I'm closest to
+perfect lack of knowledge about something is before I've built it[2].
+So, that's the best time to document it.
+
+I understand what I'm trying to tell you better now that I've written it
+down than I did when I started. Hopefully you do too.
+
+----
+
+[1] I'll often write a bug report down even if I have found the bug myself
+    and am going to fix it myself on the same day.
+    [example](http://git-annex.branchable.com/bugs/checksum_loads_whole_file_into_memory/) 
+    This is one place where it's
+    nice to have bug reports as files in the same repository as the code,
+    so that the bug report can be included in the commit fixing it. Often
+    the bug report has lots of details that don't need to go into the
+    commit message, but explain more about my evolving thinking about
+    a problem.
+
+[2] Technically I'm even more clueless ten years later when I've totally
+    forgotten whatever, but it's not practical to wait. ;-)

add news item for moreutils 0.58
diff --git a/code/moreutils/news/version_0.53.mdwn b/code/moreutils/news/version_0.53.mdwn
deleted file mode 100644
index 4a86bd2..0000000
--- a/code/moreutils/news/version_0.53.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-moreutils 0.53 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Orphaned the Debian package."""]]
\ No newline at end of file
diff --git a/code/moreutils/news/version_0.58.mdwn b/code/moreutils/news/version_0.58.mdwn
new file mode 100644
index 0000000..6d5ada3
--- /dev/null
+++ b/code/moreutils/news/version_0.58.mdwn
@@ -0,0 +1,6 @@
+moreutils 0.58 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * OpenBSD compile fix.
+     Thanks, Michael Reed.
+   * ts: Quiet perl's complaints about utf-8. Closes: #[812143](http://bugs.debian.org/812143)
+     Thanks, Nicolas Schier."""]]
\ No newline at end of file