Recent changes to this wiki:

test
diff --git a/languages/discussion.mdwn b/languages/discussion.mdwn
index 7fe07891..96731bdb 100644
--- a/languages/discussion.mdwn
+++ b/languages/discussion.mdwn
@@ -5,5 +5,5 @@ I know you mention JS. Though what about other 'languages' of the Web API puzzle
 
 Keep on hacking on Web applications Joey. You're very good at it. :)
 
-> Unlike English and Perl, HTML and CSS are not Turing complete, so they're
-> not languages. --[[Joey]]
+> Unlike English and Perl, HTML and CSS are not Turing complete
+> (barring horriible hacks), so they're not languages. --[[Joey]]

typo
diff --git a/blog/entry/two_security_holes_and_a_new_library.mdwn b/blog/entry/two_security_holes_and_a_new_library.mdwn
index 2f92be0f..abaa505c 100644
--- a/blog/entry/two_security_holes_and_a_new_library.mdwn
+++ b/blog/entry/two_security_holes_and_a_new_library.mdwn
@@ -33,7 +33,7 @@ such private data, the confusion can result in private data being exposed.
 See [the_advisory](https://git-annex.branchable.com/security/CVE-2018-10857_and_CVE-2018-10859/)
 for details.
 
-Fixing this kind of security hoole is not necessarily easy, because we use
+Fixing this kind of security hole is not necessarily easy, because we use
 HTTP libraries, often via an API library, which may not give much
 control over following redirects. DNS rebinding attacks can be 
 used to defeat security checks, if the HTTP library doesn't expose 

RESTLESS
diff --git a/blog/entry/two_security_holes_and_a_new_library.mdwn b/blog/entry/two_security_holes_and_a_new_library.mdwn
index 317064bb..2f92be0f 100644
--- a/blog/entry/two_security_holes_and_a_new_library.mdwn
+++ b/blog/entry/two_security_holes_and_a_new_library.mdwn
@@ -14,6 +14,8 @@ remotes) that uses HTTP. And quite likely beyond git-annex to unrelated
 programs, but I'll let their developers talk about that. So quite a lot of
 people were involved in this behind the scenes.
 
+See also: [The RESTLESS Vulnerability: Non-Browser Based Cross-Domain HTTP Request Attacks](https://www.danieldent.com/blog/restless-vulnerability-non-browser-cross-domain-http-request-attacks/)
+
 And then there was the second security hole in git-annex, which took
 several days to notice, in collaboration with Daniel Dent. That one's
 potentially very nasty, allowing decryption of arbitrary gpg-encrypted

blog
diff --git a/blog/entry/two_security_holes_and_a_new_library.mdwn b/blog/entry/two_security_holes_and_a_new_library.mdwn
new file mode 100644
index 00000000..317064bb
--- /dev/null
+++ b/blog/entry/two_security_holes_and_a_new_library.mdwn
@@ -0,0 +1,61 @@
+For the past week and a half, I've been working on embargoed
+[security holes](https://git-annex.branchable.com/security/CVE-2018-10857_and_CVE-2018-10859/). 
+The embargo is over, and git-annex 6.20180626 has been
+[released](https://git-annex.branchable.com/news/security_fix_release/), 
+fixing those holes. I'm also announcing a new Haskell library, 
+[[code/http-client-restricted]], which could be used to avoid
+similar problems in other programs.
+
+Working in secret under a security embargo is mostly new to me, and I
+mostly don't like it, but it seems to have been the right call in this
+case. The first security hole I found in git-annex turned out to have a
+wider impact, affecting code in git-annex plugins (aka external special
+remotes) that uses HTTP. And quite likely beyond git-annex to unrelated
+programs, but I'll let their developers talk about that. So quite a lot of
+people were involved in this behind the scenes.
+
+And then there was the second security hole in git-annex, which took
+several days to notice, in collaboration with Daniel Dent. That one's
+potentially very nasty, allowing decryption of arbitrary gpg-encrypted
+files, although exploiting it would be hard. It logically
+followed from the first security hole, so it's good that the first
+security hole was under embagro long enough for us to think it all
+though.
+
+These security holes involved HTTP servers doing things to exploit
+clients that connect to them. For example, a HTTP server that a client asks
+for the content of a file stored on it can redirect to a file://
+on the client's disk, or to http://localhost/ or a private web server on
+the client's internal network. Once the client is tricked into downloading
+such private data, the confusion can result in private data being exposed.
+See [the_advisory](https://git-annex.branchable.com/security/CVE-2018-10857_and_CVE-2018-10859/)
+for details.
+
+Fixing this kind of security hoole is not necessarily easy, because we use
+HTTP libraries, often via an API library, which may not give much
+control over following redirects. DNS rebinding attacks can be 
+used to defeat security checks, if the HTTP library doesn't expose 
+the IP address it's connecting to.
+
+I faced this problem in git-annex's use of the Haskell
+[http-client](https://hackage.haskell.org/package/http-client/) library.
+So I had to write a new library, [[code/http-client-restricted]]. Thanks
+to the good design of the http-client library, particularly its Manager
+abstraction, my library extends it rather than needing to replace it,
+and can be used with any API library built on top of http-client.
+
+I get the impression that a lot of other language's HTTP libraries need
+to have similar things developed. Much like web browsers need to enforce
+same-origin policies, HTTP clients need to be able to reject certain
+redirects according to the security needs of the program using them.
+
+I kept a private journal while working on these security holes, and am
+publishing it now:
+
+* [day 1](https://git-annex.branchable.com/devblog/day_499__security_hole/)
+* [day 2](https://git-annex.branchable.com/devblog/day_500__security_hole_part_2/)
+* [day 3](https://git-annex.branchable.com/devblog/day_501__security_hole_part_3/)
+* [day 4](https://git-annex.branchable.com/devblog/day_502__security_hole_part_4/)
+* [day 5](https://git-annex.branchable.com/devblog/day_503__security_hole_part_5/)
+* [day 6](https://git-annex.branchable.com/devblog/day_504__security_hole_part_6/)
+* [day 7](https://git-annex.branchable.com/devblog/day_505__security_fix_release/)

new project
diff --git a/code.mdwn b/code.mdwn
index 1e8dec56..612043a0 100644
--- a/code.mdwn
+++ b/code.mdwn
@@ -15,9 +15,9 @@ The stuff that's swapped into my local cache at the moment.
 [[ikiwiki]]
 [[moreutils]]
 [[ikiwiki-hosting]]
-[[github-backup]]
 [[shell-monad]]
 [[reactive-banana-automation]]
+[[http-client-restricted]]
 [[easy-peasy-devicetree-squeezy]]
 [[scuttlebutt-types]]
 
@@ -33,6 +33,7 @@ In maintenance mode mostly, but I still have my hands in it somewhat.
 [[brainfuck-monad]]
 [[zxcvbn-c]]
 [[scroll]]
+[[github-backup]]
 
 ## Past projects
 
diff --git a/code/http-client-restricted.mdwn b/code/http-client-restricted.mdwn
new file mode 100644
index 00000000..4c47b212
--- /dev/null
+++ b/code/http-client-restricted.mdwn
@@ -0,0 +1,3 @@
+restricting the servers that http-client will use
+
+<http://hackage.haskell.org/package/http-client-restricted>

response
diff --git a/blog/entry/unifying_OS_installation_and_configuration_management/comment_2_cdf45b4ef0f72fdacba1cfeb6c3d3b09._comment b/blog/entry/unifying_OS_installation_and_configuration_management/comment_2_cdf45b4ef0f72fdacba1cfeb6c3d3b09._comment
new file mode 100644
index 00000000..c37bf6d7
--- /dev/null
+++ b/blog/entry/unifying_OS_installation_and_configuration_management/comment_2_cdf45b4ef0f72fdacba1cfeb6c3d3b09._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-06-13T14:21:30Z"
+ content="""
+Propellor tracks which OS's a property supports at the type level. So to
+add a new OS, you have to at least add the types for it.
+
+I imagine that UnixLike should cover Nixos well enough for most things,
+but perhaps there will be some places Nix diverges too much from standard
+unix practice for that to work, perhaps something to do with filesystem
+layout.
+
+If you look for "Arch Linux" in the git log you'll find a patch set that is
+a good example of the kind of changes you'll need to make.
+"""]]

Added a comment: NixOS Support
diff --git a/blog/entry/unifying_OS_installation_and_configuration_management/comment_1_d310c46c1581fa1c6807580d9a613364._comment b/blog/entry/unifying_OS_installation_and_configuration_management/comment_1_d310c46c1581fa1c6807580d9a613364._comment
new file mode 100644
index 00000000..a913cf6e
--- /dev/null
+++ b/blog/entry/unifying_OS_installation_and_configuration_management/comment_1_d310c46c1581fa1c6807580d9a613364._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="craige"
+ avatar="http://cdn.libravatar.org/avatar/64ac5816ea3a51347d1f699022d1fdc1"
+ subject="NixOS Support"
+ date="2018-06-13T06:50:28Z"
+ content="""
+G'day Joey. Loving this body of work. Thank you.
+
+After 20+ years of Debian everywhere, I switched to NixOS on my desktop 5 weeks ago.
+
+I'd like to keep using Propellor for that NixOS machine as well as my Debian fleet.
+
+Before I started trying to hack in support for NixOS, I thought I'd run a sanity check up the flag pole: is hacking in NixOS something I will actually need to do? (or does \"Unixlike\" cover most of my scenarios?)
+"""]]

`vidir` should be able to copy files as well
diff --git a/code/moreutils/discussion.mdwn b/code/moreutils/discussion.mdwn
index d54ca26b..d05982cc 100644
--- a/code/moreutils/discussion.mdwn
+++ b/code/moreutils/discussion.mdwn
@@ -289,8 +289,13 @@ Another improvement would be the addition would be to add checkboxes to control
 >> (although I'm not particularly interested in this, I only use git and tig is an
 >> excellent command-line utility to manage the repository). --G. Bilotta
 
+---
+
 How about adding copying ability to vidir?
 Items are recognized by the leading number in a line, right? A second instance of the same number should imply copying.
+> I tried using `vidir` like that today as I thought it had this feature already, but it doesn’t. Something like `%s/\(.*\)one\(.*\)/&\r\1two\2` (in `vim`) should copy every file containing “one” and replace it with “two” in the copy. That’s not too hard to add as a feature, or is it? -- K. Stephan
+
+---
 
 vidir is great, but when editing and deciding to abandon the sesssion,
 deleting the entire buffer should abort (like git commit messages) instead of

Added a comment: Can't really blame GitHub?
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_13_9b9caf8ab0be162f761e958a3452f4fb._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_13_9b9caf8ab0be162f761e958a3452f4fb._comment
new file mode 100644
index 00000000..252bc143
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_13_9b9caf8ab0be162f761e958a3452f4fb._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://milki.include-once.org/"
+ nickname="Mario"
+ avatar="http://cdn.libravatar.org/avatar/697b7e012d3908ba50728345a55969aa66635185ee363c20e5be90b54e6c5e9f"
+ subject="Can't really blame GitHub?"
+ date="2018-06-08T02:08:45Z"
+ content="""
+They both popularized and exploited a few design flaws of git. Rushing all eggs into another centralized basket is not really the lesson to be learned here.
+
+Git is not the only DVCS. It's just the one clinging to repositories-are-fileshrubbery thing. Nobody HAS TO make do with it merely because it's popular (again, GitHubs fault). Decentralization buys you nothing with an implied monoculture.
+"""]]

update link
diff --git a/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn b/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn
index 0cc02340..fc20c5af 100644
--- a/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn
+++ b/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn
@@ -38,7 +38,7 @@ used for something else (and to partly tackle the problem of using
 real-world time events when the underlying FRP library uses its own
 notion of time).
 
-[The code for my fridge](https://git.joeyh.name/index.cgi/joey/homepower.git/tree/reactive.hs#n72) 
+[The code for my fridge](https://git.joeyh.name/index.cgi/joey/homepower.git/tree/src/Automation/Fridge.hs) 
 is a work in progress since the fridge has not arrived yet, and because
 the question of in which situations an offgrid fridge should optimally 
 run and not run is really rather complicated.

response
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_12_11b5adc692c6d69b9596d3165fd5613d._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_12_11b5adc692c6d69b9596d3165fd5613d._comment
new file mode 100644
index 00000000..e4a49940
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_12_11b5adc692c6d69b9596d3165fd5613d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""rate limit"""
+ date="2018-06-07T19:03:24Z"
+ content="""
+ Checking each issue for new comments takes an API call. The API is paginated == more API calls the more issues and comments there are. Finding comments attached to commits is additional API calls (and there was not a way to discover them other than trying every commit in turn last I checked). Repositories can have forks, which can have issues, which can have comments, for piles more API calls. (I know about this in some detail because I've written software to deal with all of it. It's constantly rate limited.)
+
+And then, most developers are not involved with a single software project. It's not uncommon to have dozens of dependencies you want to keep an eye on or are tangentially involved with in your work on a single project. Out of all your other projects.
+
+12 hours to check something out is not fertile ground for a distributed ecosystem to develop: As evidence see the lack of such an ecosystem.
+"""]]

Added a comment: Man management-level folks are older...
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_11_2e58412a6dde814e36d6acb786f35bc5._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_11_2e58412a6dde814e36d6acb786f35bc5._comment
new file mode 100644
index 00000000..baa733df
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_11_2e58412a6dde814e36d6acb786f35bc5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jason@84909c980a155d150ac3c9b2063e6248ee136634"
+ nickname="jason"
+ avatar="http://cdn.libravatar.org/avatar/445e077e0b53b5b104c2bfc969792a17"
+ subject="Man management-level folks are older..."
+ date="2018-06-07T13:11:55Z"
+ content="""
+I wonder how many closed-source companies using github have managers that remember \"DOS ain't done 'till Lotus don't run\" and are regretting making their family jewels available to MS.  And someone else being payed for it.
+
+I haven't seen the closed-source, private repo contracts, so they might have appropriate protections.
+"""]]

Added a comment: SIT
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_10_89ab048df6679b32af3cd412a00b89f2._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_10_89ab048df6679b32af3cd412a00b89f2._comment
new file mode 100644
index 00000000..77a07327
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_10_89ab048df6679b32af3cd412a00b89f2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yrashk"
+ avatar="http://cdn.libravatar.org/avatar/ae2b294e24fd2e472bfca45ab19050c5"
+ subject="SIT"
+ date="2018-06-06T20:54:30Z"
+ content="""
+I wholeheartedly agree on the vendor lock-in with issues and pull requests. I've had a feeling that GitHub sort of well-intendedly hijacked open source communities. A few months ago, that pushed me to develop a resilient, future-proof, decentralized issue tracker that I later generalized for other problems as well ([SIT](https://sit.fyi)). I wrote a bit about my vision when I first announced it: [“Under the Covers of Code”](https://hackernoon.com/under-the-covers-of-code-3c4761fe965a)
+
+I really wanted to build something as future-proof and resilient as I can imagine, so SIT ended up not being specific to Git or any other SCM but instead relies on simple additive sets of files.
+"""]]

removed
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_7_0d1756dc1dc4bacc18be8d494b019ce9._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_7_0d1756dc1dc4bacc18be8d494b019ce9._comment
deleted file mode 100644
index d7611c3c..00000000
--- a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_7_0d1756dc1dc4bacc18be8d494b019ce9._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="yrashk"
- avatar="http://cdn.libravatar.org/avatar/ae2b294e24fd2e472bfca45ab19050c5"
- subject="comment 7"
- date="2018-06-06T19:36:34Z"
- content="""
-I wholeheartedly agree on the vendor lock-in with issues and pull requests. I've had a feeling that GitHub sort of well-intentedly hijacked open source communities. A few months ago, that pushed me to develop a resilient, future-proof, decentralized issue tracker that I later federalized for other problems as well ([SIT](https://sit.fyi)). I wrote a bit about my vision when I first announced it: [“Under the Covers of Code”](https://hackernoon.com/under-the-covers-of-code-3c4761fe965a). I wanted to build something really future-proof so I didn't opt to make it just git-based, but rather file-based and merge-conflict-free so it can be used with any SCM (or even without one)
-
-Maybe you'll find it useful.
-"""]]

Added a comment
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_10_36cc922c4ee94bbd42acd9141af93f2b._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_10_36cc922c4ee94bbd42acd9141af93f2b._comment
new file mode 100644
index 00000000..f1797f0d
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_10_36cc922c4ee94bbd42acd9141af93f2b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="gramplestramp"
+ avatar="http://cdn.libravatar.org/avatar/9867d203519e089dc247072a4c8ab730"
+ subject="comment 10"
+ date="2018-06-06T20:00:16Z"
+ content="""
+The API rate limit is 5000 requests per hour. If that's a barrier to you extracting your project data, then you're clearly doing something wrong.
+
+Also, the word you're looking for is \"criterion\". Be more precise in your vocabulary!
+"""]]

removed
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_11_5623dc7ba19a13e412bd0aa85cc960d1._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_11_5623dc7ba19a13e412bd0aa85cc960d1._comment
deleted file mode 100644
index 2c4d1bf7..00000000
--- a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_11_5623dc7ba19a13e412bd0aa85cc960d1._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="joeyh.name-20180606@c06bf6e0535bd537459660ee51f038ff70082861"
- nickname="joeyh.name-20180606"
- avatar="http://cdn.libravatar.org/avatar/838f7b4df8043e9a45ba50f9a178beab"
- subject="gists and wikis"
- date="2018-06-06T19:49:25Z"
- content="""
-> Consider all the data that's used to provide the value-added features on top of git. Issue tracking, wikis, notes in commits, lists of forks, pull requests, access controls, hooks, other configuration, etc.
-> Is that data stored in a git repository?
->
-> Github avoids doing that 
-
-Not quite true. Both gists and wiki pages are backed by git.
-"""]]

removed
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_10_fe8fae6de275b86ad2f72da5e8f804f6._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_10_fe8fae6de275b86ad2f72da5e8f804f6._comment
deleted file mode 100644
index 81e5adc1..00000000
--- a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_10_fe8fae6de275b86ad2f72da5e8f804f6._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="joeyh.name-20180606@c06bf6e0535bd537459660ee51f038ff70082861"
- nickname="joeyh.name-20180606"
- avatar="http://cdn.libravatar.org/avatar/838f7b4df8043e9a45ba50f9a178beab"
- subject="gists and wikis"
- date="2018-06-06T19:49:18Z"
- content="""
-> Consider all the data that's used to provide the value-added features on top of git. Issue tracking, wikis, notes in commits, lists of forks, pull requests, access controls, hooks, other configuration, etc.
-> Is that data stored in a git repository?
->
-> Github avoids doing that 
-
-Not quite true. Both gists and wiki pages are backed by git.
-"""]]

Added a comment: gists and wikis
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_11_5623dc7ba19a13e412bd0aa85cc960d1._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_11_5623dc7ba19a13e412bd0aa85cc960d1._comment
new file mode 100644
index 00000000..2c4d1bf7
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_11_5623dc7ba19a13e412bd0aa85cc960d1._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joeyh.name-20180606@c06bf6e0535bd537459660ee51f038ff70082861"
+ nickname="joeyh.name-20180606"
+ avatar="http://cdn.libravatar.org/avatar/838f7b4df8043e9a45ba50f9a178beab"
+ subject="gists and wikis"
+ date="2018-06-06T19:49:25Z"
+ content="""
+> Consider all the data that's used to provide the value-added features on top of git. Issue tracking, wikis, notes in commits, lists of forks, pull requests, access controls, hooks, other configuration, etc.
+> Is that data stored in a git repository?
+>
+> Github avoids doing that 
+
+Not quite true. Both gists and wiki pages are backed by git.
+"""]]

Added a comment: gists and wikis
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_10_fe8fae6de275b86ad2f72da5e8f804f6._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_10_fe8fae6de275b86ad2f72da5e8f804f6._comment
new file mode 100644
index 00000000..81e5adc1
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_10_fe8fae6de275b86ad2f72da5e8f804f6._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joeyh.name-20180606@c06bf6e0535bd537459660ee51f038ff70082861"
+ nickname="joeyh.name-20180606"
+ avatar="http://cdn.libravatar.org/avatar/838f7b4df8043e9a45ba50f9a178beab"
+ subject="gists and wikis"
+ date="2018-06-06T19:49:18Z"
+ content="""
+> Consider all the data that's used to provide the value-added features on top of git. Issue tracking, wikis, notes in commits, lists of forks, pull requests, access controls, hooks, other configuration, etc.
+> Is that data stored in a git repository?
+>
+> Github avoids doing that 
+
+Not quite true. Both gists and wiki pages are backed by git.
+"""]]

Added a comment: gists and wikis
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_9_723355b3f8c2592230f474d19b5533ed._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_9_723355b3f8c2592230f474d19b5533ed._comment
new file mode 100644
index 00000000..65f571db
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_9_723355b3f8c2592230f474d19b5533ed._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joeyh.name-20180606@c06bf6e0535bd537459660ee51f038ff70082861"
+ nickname="joeyh.name-20180606"
+ avatar="http://cdn.libravatar.org/avatar/838f7b4df8043e9a45ba50f9a178beab"
+ subject="gists and wikis"
+ date="2018-06-06T19:49:03Z"
+ content="""
+> Consider all the data that's used to provide the value-added features on top of git. Issue tracking, wikis, notes in commits, lists of forks, pull requests, access controls, hooks, other configuration, etc.
+> Is that data stored in a git repository?
+>
+> Github avoids doing that 
+
+Not quite true. Both gists and wiki pages are backed by git.
+"""]]

Added a comment: Pagure as a replacement for GitHub
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_8_dce62f1de299f02120160e08bc4d4661._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_8_dce62f1de299f02120160e08bc4d4661._comment
new file mode 100644
index 00000000..c06f1e6f
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_8_dce62f1de299f02120160e08bc4d4661._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://ngompa.id.fedoraproject.org/"
+ nickname="ngompa"
+ avatar="http://cdn.libravatar.org/avatar/af8a9293484ed04b89081d848929b19a"
+ subject="Pagure as a replacement for GitHub"
+ date="2018-06-06T19:45:10Z"
+ content="""
+> Consider all the data that's used to provide the value-added features on top of git. Issue tracking, wikis, notes in commits, lists of forks, pull requests, access controls, hooks, other configuration, etc.
+> **Is that data stored in a git repository?**
+
+Fedora's [Pagure](https://pagure.io/pagure) mostly satisfies this requirement. All issues, comments, PR metadata, etc. are stored as Git repositories internally. You can pull, commit, and push through it that way. It also supports \"remote pull requests\" where the git repository of the source branch isn't hosted on the same server as the repo being targeted. The source repo doesn't even have to run Pagure!
+
+It uses Gitolite underneath to manage ACLs, and that isn't managed through Git repos, but instead through the application with settings in the database. But I'd argue all the meaningful information is available in a useful form.
+"""]]

Added a comment
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_7_0d1756dc1dc4bacc18be8d494b019ce9._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_7_0d1756dc1dc4bacc18be8d494b019ce9._comment
new file mode 100644
index 00000000..d7611c3c
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_7_0d1756dc1dc4bacc18be8d494b019ce9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yrashk"
+ avatar="http://cdn.libravatar.org/avatar/ae2b294e24fd2e472bfca45ab19050c5"
+ subject="comment 7"
+ date="2018-06-06T19:36:34Z"
+ content="""
+I wholeheartedly agree on the vendor lock-in with issues and pull requests. I've had a feeling that GitHub sort of well-intentedly hijacked open source communities. A few months ago, that pushed me to develop a resilient, future-proof, decentralized issue tracker that I later federalized for other problems as well ([SIT](https://sit.fyi)). I wrote a bit about my vision when I first announced it: [“Under the Covers of Code”](https://hackernoon.com/under-the-covers-of-code-3c4761fe965a). I wanted to build something really future-proof so I didn't opt to make it just git-based, but rather file-based and merge-conflict-free so it can be used with any SCM (or even without one)
+
+Maybe you'll find it useful.
+"""]]

Added a comment: git-dit
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_6_3a87a89f1b4f243bc2bbff95a058f43a._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_6_3a87a89f1b4f243bc2bbff95a058f43a._comment
new file mode 100644
index 00000000..0428573e
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_6_3a87a89f1b4f243bc2bbff95a058f43a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="girst"
+ avatar="http://cdn.libravatar.org/avatar/109c4908433659b8675806b7ba06d980"
+ subject="git-dit"
+ date="2018-06-06T19:19:59Z"
+ content="""
+There is some effort to get issues into the repository itself: https://github.com/neithernut/git-dit
+
+
+"""]]

username
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_3_2b686b0c4167535126dae9a60be89503._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_3_2b686b0c4167535126dae9a60be89503._comment
index 06a83aa3..99cd0b66 100644
--- a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_3_2b686b0c4167535126dae9a60be89503._comment
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_3_2b686b0c4167535126dae9a60be89503._comment
@@ -1,5 +1,5 @@
 [[!comment format=mdwn
- username="joeyh@52ab0fe1b447869e9a584778dae52170a7f5a3a6"
+ username="colbyrussell"
  nickname="colbyrussell"
  avatar="http://cdn.libravatar.org/avatar/2d590c8209c6af9b181dcd151a639c1f"
  subject="Git repos and abstraction level"
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_4_1f56947aac0f997fe1bb24acd15a8217._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_4_1f56947aac0f997fe1bb24acd15a8217._comment
index 791e84bb..8392c090 100644
--- a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_4_1f56947aac0f997fe1bb24acd15a8217._comment
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_4_1f56947aac0f997fe1bb24acd15a8217._comment
@@ -1,5 +1,5 @@
 [[!comment format=mdwn
- username="joeyh@52ab0fe1b447869e9a584778dae52170a7f5a3a6"
+ username="colbyrussell"
  nickname="colbyrussell"
  avatar="http://cdn.libravatar.org/avatar/2d590c8209c6af9b181dcd151a639c1f"
  subject="comment 4"

response
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_3_2b686b0c4167535126dae9a60be89503._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_3_2b686b0c4167535126dae9a60be89503._comment
index 0e6ac226..06a83aa3 100644
--- a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_3_2b686b0c4167535126dae9a60be89503._comment
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_3_2b686b0c4167535126dae9a60be89503._comment
@@ -1,6 +1,6 @@
 [[!comment format=mdwn
  username="joeyh@52ab0fe1b447869e9a584778dae52170a7f5a3a6"
- nickname="joeyh"
+ nickname="colbyrussell"
  avatar="http://cdn.libravatar.org/avatar/2d590c8209c6af9b181dcd151a639c1f"
  subject="Git repos and abstraction level"
  date="2018-06-06T18:13:15Z"
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_4_1f56947aac0f997fe1bb24acd15a8217._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_4_1f56947aac0f997fe1bb24acd15a8217._comment
index 58f251bf..791e84bb 100644
--- a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_4_1f56947aac0f997fe1bb24acd15a8217._comment
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_4_1f56947aac0f997fe1bb24acd15a8217._comment
@@ -1,6 +1,6 @@
 [[!comment format=mdwn
  username="joeyh@52ab0fe1b447869e9a584778dae52170a7f5a3a6"
- nickname="joeyh"
+ nickname="colbyrussell"
  avatar="http://cdn.libravatar.org/avatar/2d590c8209c6af9b181dcd151a639c1f"
  subject="comment 4"
  date="2018-06-06T18:17:23Z"
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_5_2389223ef35c20ee06996c54c7a8d5ec._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_5_2389223ef35c20ee06996c54c7a8d5ec._comment
new file mode 100644
index 00000000..61cdd80d
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_5_2389223ef35c20ee06996c54c7a8d5ec._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-06-06T18:22:43Z"
+ content="""
+@colbyrussell, my guess is you logged in by email with
+joeyh@yourdomain.com. I've adjusted the nickname displayed.
+
+To your point: I have done a fair bit of exploration of what makes sense to
+shoehorn into git and how to do it, and issues and PRs and project
+configuration data are really pretty trivial to do. And it's been done,
+many times before -- <https://dist-bugs.branchable.com/> -- but
+<https://xkcd.com/927/> applies to those efforts. So I'm not suggesting
+this from a naive position.
+
+And while your logic is impeccible, so is the relentless logic of VC backed
+startups and how they develop. No criteria are perfect (see above footnote), 
+but I do feel this is a good one, and better in this case than 
+"is it free software?" for pointing in the direction of some solutions.
+(Combine the two criteria and you get the 
+[Franklin Street Statement](http://wiki.p2pfoundation.net/Franklin_Street_Statement_on_Freedom_and_Network_Services)..)
+"""]]

Added a comment
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_4_1f56947aac0f997fe1bb24acd15a8217._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_4_1f56947aac0f997fe1bb24acd15a8217._comment
new file mode 100644
index 00000000..58f251bf
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_4_1f56947aac0f997fe1bb24acd15a8217._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joeyh@52ab0fe1b447869e9a584778dae52170a7f5a3a6"
+ nickname="joeyh"
+ avatar="http://cdn.libravatar.org/avatar/2d590c8209c6af9b181dcd151a639c1f"
+ subject="comment 4"
+ date="2018-06-06T18:17:23Z"
+ content="""
+I don't know why that comment is showing up as coming from \"joeyh\"; that's actually me (@colbyrussell.com), and I didn't select any option to attribute it to \"joeyh\" (or in any other way, for that matter).
+"""]]

Added a comment: Git repos and abstraction level
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_3_2b686b0c4167535126dae9a60be89503._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_3_2b686b0c4167535126dae9a60be89503._comment
new file mode 100644
index 00000000..0e6ac226
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_3_2b686b0c4167535126dae9a60be89503._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joeyh@52ab0fe1b447869e9a584778dae52170a7f5a3a6"
+ nickname="joeyh"
+ avatar="http://cdn.libravatar.org/avatar/2d590c8209c6af9b181dcd151a639c1f"
+ subject="Git repos and abstraction level"
+ date="2018-06-06T18:13:15Z"
+ content="""
+That first paragraph is a killer opener, like a song that's ridiculously good by how brutal it manages to be because of the way every line packs a punch.
+
+Having said that, it doesn't follow that because GitHub made deliberate choices for anticompetitive lock-in, then another solution—say, a P2P one—should therefore store projects' \"extras\" in Git repos.
+
+In other words:
+
+*If $PARTY had chosen Git for $USECASE, it wouldn't have let them achieve lock-in*, does not mean, *project extras stored in something besides Git necessarily results in lock-in*.  It's possible that Git repos are the entirely wrong abstraction for this.  Indeed, insisting on stuffing all the auxiliary stuff into Git, too, (and all the implications of choosing those constraints) strongly smells of that phenomenon where people pick up one abstraction and then try to shoehorn it in everywhere else, regardless of whether it's well-suited for that use case or not.  I write this even knowing your affinity and relationship to Git with git-annex & co.
+"""]]

comment
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_2_20dc6365bc57456c7b44aa368e2f9819._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_2_20dc6365bc57456c7b44aa368e2f9819._comment
new file mode 100644
index 00000000..b125dbe2
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_2_20dc6365bc57456c7b44aa368e2f9819._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-06-06T17:49:53Z"
+ content="""
+And data is the plural of datum. Except in common usage neither is.
+
+And this kind of pedantry feels like a tactic. 
+
+Oh, and your comment was committed to git, so at least it demonstrated
+something useful.
+"""]]

Correct a spelling mistake.
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn b/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn
index cc651ff3..7dd36d5d 100644
--- a/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn
@@ -1,4 +1,4 @@
-I could write a lot of things about the Github aquisition by Microsoft.
+I could write a lot of things about the Github acquisition by Microsoft.
 About Github's embrace and extend of git, and how it passed unnoticed by
 people who now fear the same thing now that Microsoft is in the
 picture. About the stultifying effects of Github's centralization, and

Added a comment: Criteria
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_1_0d77a12534da43028d5eacdc3b25a660._comment b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_1_0d77a12534da43028d5eacdc3b25a660._comment
new file mode 100644
index 00000000..3b3d87be
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github/comment_1_0d77a12534da43028d5eacdc3b25a660._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="moses.skoda@5596bce29110454b6f2f526c9ebd0c6b123bee49"
+ nickname="moses.skoda"
+ avatar="http://cdn.libravatar.org/avatar/df1440e57234792f07c901384e07ef6b"
+ subject="Criteria"
+ date="2018-06-06T17:28:30Z"
+ content="""
+Hi, just an FYI that I thought might be appreciated: *criteria* is a plural form of the word *criterion*
+"""]]

clarify
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn b/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn
index e759e763..cc651ff3 100644
--- a/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn
@@ -35,5 +35,5 @@ an opportunity to get us out of the trap we now find ourselves in.
 
 [1] Although in the case of a P2P system which uses a distributed data
 structure, that can have many of the same benefits as using git. 
-So I'd give git-ssb, which stores issues etc as ssb messages, a pass
-on this, for example.
+So, git-ssb, which stores issues etc as ssb messages, is just as good,
+for example.

fix link
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn b/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn
index 776ab030..e759e763 100644
--- a/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn
@@ -14,7 +14,7 @@ top of git. Issue tracking, wikis, notes in commits, lists of forks, pull
 requests, access controls, hooks, other configuration, etc.  
 **Is that data stored in a git repository?**
 
-Github [avoids doing that](a_Github_survey) and there's a good
+Github [[avoids doing that|a_Github_survey]] and there's a good
 reason why: By keeping this data in their own database, they lock you into
 the service. Consider if Github issues had been stored in a git repository
 next to the code. Anyone could quickly and easily clone the issue data,

blog update
diff --git a/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn b/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn
new file mode 100644
index 00000000..776ab030
--- /dev/null
+++ b/blog/entry/the_single_most_important_criteria_when_replacing_Github.mdwn
@@ -0,0 +1,39 @@
+I could write a lot of things about the Github aquisition by Microsoft.
+About Github's embrace and extend of git, and how it passed unnoticed by
+people who now fear the same thing now that Microsoft is in the
+picture. About the stultifying effects of Github's centralization, and
+its retardant effect on general innovation in spaces around git and
+software development infrastructure.
+
+Instead I'd rather highlight one simple criteria you can consider when
+you are evaluating any git hosting service, whether it's Gitlab or
+something self-hosted, or federated, or P2P[1], or whatever:
+
+Consider all the data that's used to provide the value-added features on
+top of git. Issue tracking, wikis, notes in commits, lists of forks, pull
+requests, access controls, hooks, other configuration, etc.  
+**Is that data stored in a git repository?**
+
+Github [avoids doing that](a_Github_survey) and there's a good
+reason why: By keeping this data in their own database, they lock you into
+the service. Consider if Github issues had been stored in a git repository
+next to the code. Anyone could quickly and easily clone the issue data,
+consume it, write alternative issue tracking interfaces, which then start
+accepting git pushes of issue updates and syncing all around. That would have
+quickly became *the* de-facto distributed issue tracking data format.
+
+Instead, Github stuck it in a database, with a rate-limited API, and while
+this probably had as much to do with expediency, and a certain centralized
+mindset, as intentional lock-in at first, it's now become such good lock-in
+that Microsoft felt Github was worth $7 billion.
+
+So, if whatever thing you're looking at instead of Github doesn't do
+this, it's at worst hoping to emulate that, or at best it's neglecting
+an opportunity to get us out of the trap we now find ourselves in.
+
+----
+
+[1] Although in the case of a P2P system which uses a distributed data
+structure, that can have many of the same benefits as using git. 
+So I'd give git-ssb, which stores issues etc as ssb messages, a pass
+on this, for example.

poll vote (watched it all, liked it)
diff --git a/blog/entry/watch_me_code_for_half_an_hour.mdwn b/blog/entry/watch_me_code_for_half_an_hour.mdwn
index ca8b8fad..9a6c362d 100644
--- a/blog/entry/watch_me_code_for_half_an_hour.mdwn
+++ b/blog/entry/watch_me_code_for_half_an_hour.mdwn
@@ -14,7 +14,7 @@ Not shown is the hour I spent the next day changing the "optimize"
 subcommand implemented here into "--auto" options that can be passed to
 [[code/git-annex]]'s get and drop commands.
 
-[[!poll 48 "watched it all, liked it" 8 "watched some, boring" 4 "too long for me" 15 "too haskell for me" 13 "not interested"]]
+[[!poll 49 "watched it all, liked it" 8 "watched some, boring" 4 "too long for me" 15 "too haskell for me" 13 "not interested"]]
 
 [[!meta title="watch me program for half an hour"]]
 [[!tag haskell]]

poll vote (watched it all, liked it)
diff --git a/blog/entry/watch_me_code_for_half_an_hour.mdwn b/blog/entry/watch_me_code_for_half_an_hour.mdwn
index d80f87e9..ca8b8fad 100644
--- a/blog/entry/watch_me_code_for_half_an_hour.mdwn
+++ b/blog/entry/watch_me_code_for_half_an_hour.mdwn
@@ -14,7 +14,7 @@ Not shown is the hour I spent the next day changing the "optimize"
 subcommand implemented here into "--auto" options that can be passed to
 [[code/git-annex]]'s get and drop commands.
 
-[[!poll 47 "watched it all, liked it" 9 "watched some, boring" 4 "too long for me" 15 "too haskell for me" 13 "not interested"]]
+[[!poll 48 "watched it all, liked it" 8 "watched some, boring" 4 "too long for me" 15 "too haskell for me" 13 "not interested"]]
 
 [[!meta title="watch me program for half an hour"]]
 [[!tag haskell]]

poll vote (watched some, boring)
diff --git a/blog/entry/watch_me_code_for_half_an_hour.mdwn b/blog/entry/watch_me_code_for_half_an_hour.mdwn
index 44c6141b..d80f87e9 100644
--- a/blog/entry/watch_me_code_for_half_an_hour.mdwn
+++ b/blog/entry/watch_me_code_for_half_an_hour.mdwn
@@ -14,7 +14,7 @@ Not shown is the hour I spent the next day changing the "optimize"
 subcommand implemented here into "--auto" options that can be passed to
 [[code/git-annex]]'s get and drop commands.
 
-[[!poll 47 "watched it all, liked it" 8 "watched some, boring" 4 "too long for me" 15 "too haskell for me" 13 "not interested"]]
+[[!poll 47 "watched it all, liked it" 9 "watched some, boring" 4 "too long for me" 15 "too haskell for me" 13 "not interested"]]
 
 [[!meta title="watch me program for half an hour"]]
 [[!tag haskell]]

Added a comment: solar thermal refridgerators
diff --git a/blog/entry/fridge_0.1/comment_3_f3207590c8c6589c85a0e33c1841d928._comment b/blog/entry/fridge_0.1/comment_3_f3207590c8c6589c85a0e33c1841d928._comment
new file mode 100644
index 00000000..5967bd2f
--- /dev/null
+++ b/blog/entry/fridge_0.1/comment_3_f3207590c8c6589c85a0e33c1841d928._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~markvdb"
+ nickname="markvdb"
+ avatar="http://cdn.libravatar.org/avatar/fb7b18b417b7accd1d52371b84cd4372a919bdad7b14e931c007ffb5d2864065"
+ subject="solar thermal refridgerators"
+ date="2018-05-21T09:19:31Z"
+ content="""
+An interesting experiment might be to convert your old propane fridge to use solar thermal as its heat source. There's several open hardware experiments in the solar thermal space. Same thing for solar refridgeration.
+"""]]

fix my numbers
diff --git a/blog/entry/fridge_0.1/comment_2_595a56e187cf511dccdc318d99ec1228._comment b/blog/entry/fridge_0.1/comment_2_595a56e187cf511dccdc318d99ec1228._comment
index 0c8810d0..2c63028d 100644
--- a/blog/entry/fridge_0.1/comment_2_595a56e187cf511dccdc318d99ec1228._comment
+++ b/blog/entry/fridge_0.1/comment_2_595a56e187cf511dccdc318d99ec1228._comment
@@ -4,12 +4,12 @@
  date="2018-05-19T15:23:49Z"
  content="""
 12v fridges are also much more expensive than regular consumer goods,
-the premium is often 300%.
+the premium is often 400%.
 
 They may be a little more efficient due to better insulation. They don't
 seem to use any less watts when running.
 
-You can buy a lot of solar panels for the $600 I saved on going with a
+You can buy a lot of solar panels for the $900 I saved on going with a
 regular chest freezer. Almost as many solar panels as I am using to power
 it..
 """]]

respinse
diff --git a/blog/entry/fridge_0.1/comment_2_595a56e187cf511dccdc318d99ec1228._comment b/blog/entry/fridge_0.1/comment_2_595a56e187cf511dccdc318d99ec1228._comment
new file mode 100644
index 00000000..0c8810d0
--- /dev/null
+++ b/blog/entry/fridge_0.1/comment_2_595a56e187cf511dccdc318d99ec1228._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-05-19T15:23:49Z"
+ content="""
+12v fridges are also much more expensive than regular consumer goods,
+the premium is often 300%.
+
+They may be a little more efficient due to better insulation. They don't
+seem to use any less watts when running.
+
+You can buy a lot of solar panels for the $600 I saved on going with a
+regular chest freezer. Almost as many solar panels as I am using to power
+it..
+"""]]
diff --git a/blog/entry/my_haskell_controlled_offgrid_fridge/comment_1_3774973c089b47a2e53b2a3193d9e66e._comment b/blog/entry/my_haskell_controlled_offgrid_fridge/comment_1_3774973c089b47a2e53b2a3193d9e66e._comment
deleted file mode 100644
index e3f41978..00000000
--- a/blog/entry/my_haskell_controlled_offgrid_fridge/comment_1_3774973c089b47a2e53b2a3193d9e66e._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="Hello1992"
- avatar="http://cdn.libravatar.org/avatar/fa07ec46f84f47023bfc79d220d2f535"
- subject="Hello"
- date="2018-05-19T10:05:16Z"
- content="""
-I cum to Haskall every night, because Bjarne forces me to use a strap on. I'm a little rusty, but Ritchie said everything is going to be ok.
-"""]]

Added a comment: Fridges
diff --git a/blog/entry/fridge_0.1/comment_1_6605db89817c694041d2f13863b9c442._comment b/blog/entry/fridge_0.1/comment_1_6605db89817c694041d2f13863b9c442._comment
new file mode 100644
index 00000000..ac8a752c
--- /dev/null
+++ b/blog/entry/fridge_0.1/comment_1_6605db89817c694041d2f13863b9c442._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="regimbal.grant@92c5ff8276af4860a9d99e187752261329203361"
+ nickname="regimbal.grant"
+ avatar="http://cdn.libravatar.org/avatar/f83dfcb9d5ff90e1e881595b8c3b13b0"
+ subject="Fridges"
+ date="2018-05-19T15:09:04Z"
+ content="""
+You should look into some of the fridges used on expeditions. They are much more efficient than regular fridges and run on 12 volt systems. http://store.arbusa.com/ARB-Fridge-Freezer-50-Qt-10800472-P3626.aspx
+"""]]

Added a comment: Hello
diff --git a/blog/entry/my_haskell_controlled_offgrid_fridge/comment_1_3774973c089b47a2e53b2a3193d9e66e._comment b/blog/entry/my_haskell_controlled_offgrid_fridge/comment_1_3774973c089b47a2e53b2a3193d9e66e._comment
new file mode 100644
index 00000000..e3f41978
--- /dev/null
+++ b/blog/entry/my_haskell_controlled_offgrid_fridge/comment_1_3774973c089b47a2e53b2a3193d9e66e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Hello1992"
+ avatar="http://cdn.libravatar.org/avatar/fa07ec46f84f47023bfc79d220d2f535"
+ subject="Hello"
+ date="2018-05-19T10:05:16Z"
+ content="""
+I cum to Haskall every night, because Bjarne forces me to use a strap on. I'm a little rusty, but Ritchie said everything is going to be ok.
+"""]]

recrop
diff --git a/blog/pics/fridgecooldown.png b/blog/pics/fridgecooldown.png
index 7e98ac32..320a68e7 100644
Binary files a/blog/pics/fridgecooldown.png and b/blog/pics/fridgecooldown.png differ

blog update
diff --git a/blog/entry/fridge_0.1.mdwn b/blog/entry/fridge_0.1.mdwn
new file mode 100644
index 00000000..cbadaea0
--- /dev/null
+++ b/blog/entry/fridge_0.1.mdwn
@@ -0,0 +1,41 @@
+Imagine something really cool, like a fridge connected to a powerwall,
+powered entirely by solar panels. What could be cooler than that?
+
+How about a fridge powered entirely by solar panels without the powerwall?
+Zero battery use, and yet it still preserves your food.
+
+That's much cooler, because batteries, even hyped ones like the powerwall,
+are expensive and innefficient and have limited cycles. Solar panels are
+cheap and efficient now. With enough solar panels that the fridge has
+power to cool down most days (even cloudy days), and a smart enough
+control system, the fridge itself becomes the battery -- a cold battery.
+
+I'm live coding my fridge, with that goal in mind.
+You can follow along in
+[this design thread on secure scuttlebutt](https://viewer.scuttlebot.io/%25Pg7%2BlVNJS13o2GBftbMLC2V0BgB3PSeX1L3cVdnUifc%3D.sha256),
+and [my git commits](https://git.joeyh.name/index.cgi/joey/homepower.git/log/),
+and you can watch
+[real-time data from my fridge](http://homepower.joeyh.name/fridge.html).
+
+Over the past two days, which were not especially sunny, my 1 kilowatt of
+solar panels has managed to cool the fridge down close to standard fridge
+temperatures. The temperature remains steady overnight thanks to added
+thermal mass in the fridge. My food seems safe in it, despite it being
+powered off for 14 hours each night.
+
+[[!img pics/fridgecooldown.png alt="graph of fridge temperature, starting at 13C and trending downwards to 5C over 24 hours"]]
+
+(Numbers in this graph are running higher than the actual temps of food in
+the fridge, for reasons explained in the scuttlebutt thread.)
+
+Of course, the longterm viability of a fridge that never draws from a
+battery is TBD; I'll know within a year if it works for me.
+
+[[!img pics/bananafridge.jpg alt="bunch of bananas resting on top of chest freezer fridge conversion"]]
+
+I've written about the coding side of this project before,
+in [[my_haskell_controlled_offgrid_fridge]]. The reactive-banana-automation 
+library is working well in this application. My 
+[[AIMS inverter control board|AIMS_inverter_control_via_GPIO_ports]]
+and [[easy-peasy-devicetree-squeezy]] were other groundwork for
+this project.
diff --git a/blog/pics/fridgecooldown.png b/blog/pics/fridgecooldown.png
new file mode 100644
index 00000000..7e98ac32
Binary files /dev/null and b/blog/pics/fridgecooldown.png differ

pic
diff --git a/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn b/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn
index e3dbaee6..0cc02340 100644
--- a/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn
+++ b/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn
@@ -77,3 +77,4 @@ BTW, building a 400 line library and writing reams of control code for a
 fridge that has not been installed yet is what we Haskell programmers call
 "laziness".
 
+[[!img pics/bananafridge.jpg]]
diff --git a/blog/pics/bananafridge.jpg b/blog/pics/bananafridge.jpg
new file mode 100644
index 00000000..e8b62c07
Binary files /dev/null and b/blog/pics/bananafridge.jpg differ

add news item for pdmenu 1.3.5
diff --git a/code/pdmenu/news/version_1.3.0.mdwn b/code/pdmenu/news/version_1.3.0.mdwn
deleted file mode 100644
index 33deee2a..00000000
--- a/code/pdmenu/news/version_1.3.0.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-pdmenu 1.3.0 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Add support for "exec entries"; menu entries that pdmenu execs,
-     replacing itself with their process. Contributed by Stephen Blott
-   * Add -s switch enabling superhot mode, in which pressing an unambiguous
-     menu hotkey immediately runs that menu item. Contributed by Stephen Blott"""]]
\ No newline at end of file
diff --git a/code/pdmenu/news/version_1.3.5.mdwn b/code/pdmenu/news/version_1.3.5.mdwn
new file mode 100644
index 00000000..cc58e93f
--- /dev/null
+++ b/code/pdmenu/news/version_1.3.5.mdwn
@@ -0,0 +1,8 @@
+pdmenu 1.3.5 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Added --borderspace/-b option, which uses spaces rather than line
+     drawing characters around the menu. Mostly useful for screen readers,
+     also perhaps a more modern look.
+     Thanks to Storm Dragon for suggesting this feature.
+   * Added missing documentation for --superhot/-s to man page.
+   * Update my email address."""]]
\ No newline at end of file

format format
diff --git a/blog/entry/more_fun_with_reactive-banana-automation.mdwn b/blog/entry/more_fun_with_reactive-banana-automation.mdwn
index a5a7a4d3..d8d51377 100644
--- a/blog/entry/more_fun_with_reactive-banana-automation.mdwn
+++ b/blog/entry/more_fun_with_reactive-banana-automation.mdwn
@@ -8,17 +8,17 @@ using my [reactive-banana-automation](http://hackage.haskell.org/package/reactiv
 library is almost shorter than the English description, and certianly clearer.
 
 [[!format haskell """
-	inverterPowerChange :: Sensors t -> MomentAutomation (Behavior (Maybe PowerChange))
-	inverterPowerChange sensors = do
-	    lowpower <- lowpowerMode sensors
-	    fridgepowerchange <- fridgePowerChange sensors
-	    wifiusers <- numWifiUsers sensors
-	    return $ react <$> lowpower <*> fridgepowerchange <*> wifiusers
-	where
-	    react lowpower fridgepowerchange wifiusers
-	            | lowpower = Just PowerOff
-	            | wifiusers > 0 = Just PowerOn
-	            | otherwise = fridgepowerchange
+inverterPowerChange :: Sensors t -> MomentAutomation (Behavior (Maybe PowerChange))
+inverterPowerChange sensors = do
+    lowpower <- lowpowerMode sensors
+    fridgepowerchange <- fridgePowerChange sensors
+    wifiusers <- numWifiUsers sensors
+    return $ react <$> lowpower <*> fridgepowerchange <*> wifiusers
+where
+    react lowpower fridgepowerchange wifiusers
+            | lowpower = Just PowerOff
+            | wifiusers > 0 = Just PowerOn
+            | otherwise = fridgepowerchange
 """]]
 
 Of course, there are complexities under the hood, like where does
@@ -37,34 +37,32 @@ with this style of testing. For example, here's how it determines
 when the house needs to be in low power mode, including the tests:
 
 [[!format haskell """
-	-- | Start by assuming we're not in low power mode, to avoid
-	-- entering it before batteryVoltage is available.
-	--
-	-- If batteryVoltage continues to be unavailable, enter low power mode for
-	-- safety.
-	-- 
-	-- >>> runner <- observeAutomation (runInverterUnless lowpowerMode) (mkSensors (pure ()))
-	-- >>> runner $ \sensors -> gotEvent (dhcpClients sensors) []
-	-- []
-	-- >>> runner $ \sensors -> sensorUnavailable (batteryVoltage sensors)
-	-- [InverterPower PowerOff]
-	-- >>> runner $ \sensors -> batteryVoltage sensors =: Volts 25
-	-- [InverterPower PowerOn]
-	-- >>> runner $ \sensors -> batteryVoltage sensors =: Volts 20
-	-- [InverterPower PowerOff]
-	-- >>> runner $ \sensors -> batteryVoltage sensors =: Volts 25
-	-- [InverterPower PowerOn]
-	-- >>> runner $ \sensors -> sensorUnavailable (batteryVoltage sensors)
-	-- [InverterPower PowerOff]
-	lowpowerMode :: Sensors t -> MomentAutomation (Behavior Bool)
-	lowpowerMode sensors = automationStepper False
-		=<< fmap calc <$> getEventFrom (batteryVoltage sensors)
-	  where
-		-- Below 24.0 (really 23.5 or so) is danger zone for lead acid.
-		calc (Sensed v) = v < Volts 24.1
-		-- When battery  voltage is not known, default to low power
-		-- mode for safety.
-		calc SensorUnavailable = True
+-- | Start by assuming we're not in low power mode, to avoid
+-- entering it before batteryVoltage is available.
+--
+-- If batteryVoltage continues to be unavailable, enter low power mode for
+-- safety.
+-- 
+-- >>> runner <- observeAutomation (runInverterUnless lowpowerMode) (mkSensors (pure ()))
+-- >>> runner $ \sensors -> gotEvent (dhcpClients sensors) []
+-- []
+-- >>> runner $ \sensors -> sensorUnavailable (batteryVoltage sensors)
+-- [InverterPower PowerOff]
+-- >>> runner $ \sensors -> batteryVoltage sensors =: Volts 25
+-- [InverterPower PowerOn]
+-- >>> runner $ \sensors -> batteryVoltage sensors =: Volts 20
+-- [InverterPower PowerOff]
+-- >>> runner $ \sensors -> batteryVoltage sensors =: Volts 25
+-- [InverterPower PowerOn]
+-- >>> runner $ \sensors -> sensorUnavailable (batteryVoltage sensors)
+-- [InverterPower PowerOff]
+lowpowerMode :: Sensors t -> MomentAutomation (Behavior Bool)
+lowpowerMode sensors = automationStepper False
+	=<< fmap calc <$> getEventFrom (batteryVoltage sensors)
+  where
+	-- Below 24.0 (really 23.5 or so) is danger zone for lead acid.
+	calc (Sensed v) = v < Volts 24.1
+	calc SensorUnavailable = True
 """]]
 
 The sensor data is available over http, so I can run this controller

format format
diff --git a/blog/entry/more_fun_with_reactive-banana-automation.mdwn b/blog/entry/more_fun_with_reactive-banana-automation.mdwn
index c5209606..a5a7a4d3 100644
--- a/blog/entry/more_fun_with_reactive-banana-automation.mdwn
+++ b/blog/entry/more_fun_with_reactive-banana-automation.mdwn
@@ -36,7 +36,7 @@ the FRP code. I designed reactive-banana-automation to work well
 with this style of testing. For example, here's how it determines
 when the house needs to be in low power mode, including the tests:
 
-[[[!format haskell """
+[[!format haskell """
 	-- | Start by assuming we're not in low power mode, to avoid
 	-- entering it before batteryVoltage is available.
 	--

format format
diff --git a/blog/entry/more_fun_with_reactive-banana-automation.mdwn b/blog/entry/more_fun_with_reactive-banana-automation.mdwn
index cceddb7d..c5209606 100644
--- a/blog/entry/more_fun_with_reactive-banana-automation.mdwn
+++ b/blog/entry/more_fun_with_reactive-banana-automation.mdwn
@@ -36,7 +36,7 @@ the FRP code. I designed reactive-banana-automation to work well
 with this style of testing. For example, here's how it determines
 when the house needs to be in low power mode, including the tests:
 
-[[[format haskell """
+[[[!format haskell """
 	-- | Start by assuming we're not in low power mode, to avoid
 	-- entering it before batteryVoltage is available.
 	--

blog update
diff --git a/blog/entry/more_fun_with_reactive-banana-automation.mdwn b/blog/entry/more_fun_with_reactive-banana-automation.mdwn
new file mode 100644
index 00000000..cceddb7d
--- /dev/null
+++ b/blog/entry/more_fun_with_reactive-banana-automation.mdwn
@@ -0,0 +1,78 @@
+My house knows when people are using the wifi, and keeps the inverter on so
+that the satellite internet is powered up, unless the battery is too low.
+When nobody is using the wifi, the inverter turns off, except when it's
+needed to power the fridge.
+
+Sounds a little complicated, doesn't it? The code to automate that 
+using my [reactive-banana-automation](http://hackage.haskell.org/package/reactive-banana-automation)
+library is almost shorter than the English description, and certianly clearer.
+
+[[!format haskell """
+	inverterPowerChange :: Sensors t -> MomentAutomation (Behavior (Maybe PowerChange))
+	inverterPowerChange sensors = do
+	    lowpower <- lowpowerMode sensors
+	    fridgepowerchange <- fridgePowerChange sensors
+	    wifiusers <- numWifiUsers sensors
+	    return $ react <$> lowpower <*> fridgepowerchange <*> wifiusers
+	where
+	    react lowpower fridgepowerchange wifiusers
+	            | lowpower = Just PowerOff
+	            | wifiusers > 0 = Just PowerOn
+	            | otherwise = fridgepowerchange
+"""]]
+
+Of course, there are complexities under the hood, like where does
+`numWifiUsers` come from? (It uses inotify to detect changes to the
+DHCP leases file, and tracks when leases expire.) I'm up to 1200 lines of
+custom code for my house, only 170 lines of which are control code like
+the above. 
+
+But that code is the core, and it's where most of the bugs would be.
+The goal is to avoid most of the bugs by using FRP and Haskell
+the way I have, and the rest by testing.
+
+For testing, I'm using doctest to embed test cases along with
+the FRP code. I designed reactive-banana-automation to work well
+with this style of testing. For example, here's how it determines
+when the house needs to be in low power mode, including the tests:
+
+[[[format haskell """
+	-- | Start by assuming we're not in low power mode, to avoid
+	-- entering it before batteryVoltage is available.
+	--
+	-- If batteryVoltage continues to be unavailable, enter low power mode for
+	-- safety.
+	-- 
+	-- >>> runner <- observeAutomation (runInverterUnless lowpowerMode) (mkSensors (pure ()))
+	-- >>> runner $ \sensors -> gotEvent (dhcpClients sensors) []
+	-- []
+	-- >>> runner $ \sensors -> sensorUnavailable (batteryVoltage sensors)
+	-- [InverterPower PowerOff]
+	-- >>> runner $ \sensors -> batteryVoltage sensors =: Volts 25
+	-- [InverterPower PowerOn]
+	-- >>> runner $ \sensors -> batteryVoltage sensors =: Volts 20
+	-- [InverterPower PowerOff]
+	-- >>> runner $ \sensors -> batteryVoltage sensors =: Volts 25
+	-- [InverterPower PowerOn]
+	-- >>> runner $ \sensors -> sensorUnavailable (batteryVoltage sensors)
+	-- [InverterPower PowerOff]
+	lowpowerMode :: Sensors t -> MomentAutomation (Behavior Bool)
+	lowpowerMode sensors = automationStepper False
+		=<< fmap calc <$> getEventFrom (batteryVoltage sensors)
+	  where
+		-- Below 24.0 (really 23.5 or so) is danger zone for lead acid.
+		calc (Sensed v) = v < Volts 24.1
+		-- When battery  voltage is not known, default to low power
+		-- mode for safety.
+		calc SensorUnavailable = True
+"""]]
+
+The sensor data is available over http, so I can run this controller
+code in test mode, on my laptop, and observe how it reacts to
+real-world circumstances.
+
+	joey@darkstar:~/src/homepower>./controller test
+	InverterPower PowerOn
+	FridgeRelay PowerOff
+
+Previously: [[my haskell controlled offgrid fridge]]

add news item for scroll 1.20180421
diff --git a/code/scroll/news/version_1.20180421.mdwn b/code/scroll/news/version_1.20180421.mdwn
new file mode 100644
index 00000000..1efc75b1
--- /dev/null
+++ b/code/scroll/news/version_1.20180421.mdwn
@@ -0,0 +1,4 @@
+scroll 1.20180421 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Added stack.yaml.
+   * Fix build with ghc 8.2."""]]
\ No newline at end of file

add
diff --git a/code.mdwn b/code.mdwn
index 38a0f9ee..1e8dec56 100644
--- a/code.mdwn
+++ b/code.mdwn
@@ -17,8 +17,9 @@ The stuff that's swapped into my local cache at the moment.
 [[ikiwiki-hosting]]
 [[github-backup]]
 [[shell-monad]]
-[[scuttlebutt-types]]
+[[reactive-banana-automation]]
 [[easy-peasy-devicetree-squeezy]]
+[[scuttlebutt-types]]
 
 ## Less active projects
 
diff --git a/code/reactive-banana-automation.mdwn b/code/reactive-banana-automation.mdwn
new file mode 100644
index 00000000..0c1b7162
--- /dev/null
+++ b/code/reactive-banana-automation.mdwn
@@ -0,0 +1,3 @@
+Home automation using FRP
+
+<http://hackage.haskell.org/package/reactive-banana-automation>

layout
diff --git a/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn b/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn
index e4a15977..e3dbaee6 100644
--- a/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn
+++ b/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn
@@ -13,11 +13,11 @@ Of course, I want the control code to be as robust as possible, well
 tested, and easy to modify without making mistakes. Pure functional Haskell
 code.
 
+<img src="https://wiki.haskell.org/wikiupload/7/7c/Reactive-Banana-banana.png">
 There are many Haskell libraries for FRP, and I have not looked at most of
 them in any detail. I settled on
 [reactive-banana](https://wiki.haskell.org/Reactive-banana) because it
 has a good reputation and amazing testimonials. 
-<img src="https://wiki.haskell.org/wikiupload/7/7c/Reactive-Banana-banana.png">
 
 > "In the programming-language world, one rule of survival is simple:
 > dance or die. This library makes dancing easy." – Simon Banana Jones

blog update
diff --git a/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn b/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn
new file mode 100644
index 00000000..e4a15977
--- /dev/null
+++ b/blog/entry/my_haskell_controlled_offgrid_fridge.mdwn
@@ -0,0 +1,79 @@
+I'm preparing for a fridge upgrade, away from the tiny propane fridge to a
+chest freezer conversion. My home computer will be monitoring the
+fridge temperature and the state of my offgrid energy system, and turning the
+fridge on and off using a relay and the
+[[inverter control board|AIMS_inverter_control_via_GPIO_ports]] I built
+earlier.
+
+This kind of automation is a perfect fit for Functional Reactive
+Programming (FRP) since it's all about time-varying behaviors and events
+being combined together.
+
+Of course, I want the control code to be as robust as possible, well
+tested, and easy to modify without making mistakes. Pure functional Haskell
+code.
+
+There are many Haskell libraries for FRP, and I have not looked at most of
+them in any detail. I settled on
+[reactive-banana](https://wiki.haskell.org/Reactive-banana) because it
+has a good reputation and amazing testimonials. 
+<img src="https://wiki.haskell.org/wikiupload/7/7c/Reactive-Banana-banana.png">
+
+> "In the programming-language world, one rule of survival is simple:
+> dance or die. This library makes dancing easy." – Simon Banana Jones
+
+But, it's mostly used for GUI programming, or maybe some musical
+live-coding. There were no libraries for using reactive-banana for
+the more staid task of home automation, or anything like that. 
+Also, using it involves a whole lot of IO code, so not great for testing.
+
+So I built
+[reactive-banana-automation](http://hackage.haskell.org/package/reactive-banana-automation) 
+on top of it to address my needs. I think it's a pretty good library,
+although I don't have a deep enough grokking of FRP to say that for sure.
+
+Anyway, it's plenty flexible for my fridge automation needs, and I also
+wrote a motion-controlled light automation with it to make sure it could be
+used for something else (and to partly tackle the problem of using
+real-world time events when the underlying FRP library uses its own
+notion of time).
+
+[The code for my fridge](https://git.joeyh.name/index.cgi/joey/homepower.git/tree/reactive.hs#n72) 
+is a work in progress since the fridge has not arrived yet, and because
+the question of in which situations an offgrid fridge should optimally 
+run and not run is really rather complicated.
+
+Here's a simpler example, for a non-offgrid fridge.
+
+[[!format haskell """
+fridge :: Automation Sensors Actuators
+fridge sensors actuators = do
+        -- Create a Behavior that reflects the most recently reported
+        -- temperature of the fridge.
+        btemperature <- sensedBehavior (fridgeTemperature sensors)
+        -- Calculate when the fridge should turn on and off.
+        let bpowerchange = calcpowerchange <$> btemperature
+        onBehaviorChangeMaybe bpowerchange (actuators . FridgePower)
+  where
+        calcpowerchange (Sensed temp)
+                | temp `belowRange` allowedtemp = Just PowerOff
+                | temp `aboveRange` allowedtemp = Just PowerOn
+                | otherwise = Nothing
+        calcpowerchange SensorUnavailable = Nothing
+        allowedtemp = Range 1 4
+"""]]
+
+And here the code is being tested in a reproducible fashion:
+
+	> runner <- observeAutomation fridge mkSensors
+	> runner $ \sensors -> fridgeTemperature sensors =: 6
+	[FridgePower PowerOn]
+	> runner $ \sensors -> fridgeTemperature sensors =: 3
+	[]
+	> runner $ \sensors -> fridgeTemperature sensors =: 0.5
+	[FridgePower PowerOff]
+
+BTW, building a 400 line library and writing reams of control code for a
+fridge that has not been installed yet is what we Haskell programmers call
+"laziness".
+

rotate
diff --git a/blog/pics/aimsinvertercontrol.jpg b/blog/pics/aimsinvertercontrol.jpg
index 4ea4d086..30c8de7e 100644
Binary files a/blog/pics/aimsinvertercontrol.jpg and b/blog/pics/aimsinvertercontrol.jpg differ

scale
diff --git a/blog/entry/AIMS_inverter_control_via_GPIO_ports.mdwn b/blog/entry/AIMS_inverter_control_via_GPIO_ports.mdwn
index 784b8473..824a6187 100644
--- a/blog/entry/AIMS_inverter_control_via_GPIO_ports.mdwn
+++ b/blog/entry/AIMS_inverter_control_via_GPIO_ports.mdwn
@@ -27,8 +27,8 @@ letting it turn the inverter on and off, and also check if it's currently
 running. Built this board, which is the first PCB I've designed and built
 myself.
 
-[[!img pics/aimsinvertercontrol.jpg size=640x]]
-[[!img pics/aimsinvertercontrolschematic.jpg size=640x]]
+[[!img pics/aimsinvertercontrol.jpg size=400x]]
+[[!img pics/aimsinvertercontrolschematic.jpg size=400x]]
 
 The full schematic and haskell code to control the inverter are in
 the git repository <https://git.joeyh.name/index.cgi/joey/homepower.git/tree/>.

scale
diff --git a/blog/entry/AIMS_inverter_control_via_GPIO_ports.mdwn b/blog/entry/AIMS_inverter_control_via_GPIO_ports.mdwn
index 31071ee5..784b8473 100644
--- a/blog/entry/AIMS_inverter_control_via_GPIO_ports.mdwn
+++ b/blog/entry/AIMS_inverter_control_via_GPIO_ports.mdwn
@@ -28,7 +28,7 @@ running. Built this board, which is the first PCB I've designed and built
 myself.
 
 [[!img pics/aimsinvertercontrol.jpg size=640x]]
-[[!img pics/aimsinvertercontrolschematic.jpg]]
+[[!img pics/aimsinvertercontrolschematic.jpg size=640x]]
 
 The full schematic and haskell code to control the inverter are in
 the git repository <https://git.joeyh.name/index.cgi/joey/homepower.git/tree/>.

oops
diff --git a/blog/pics/aimsinvertercontrolschematic.jpg b/blog/pics/aimsinvertercontrolschematic.jpg
new file mode 100644
index 00000000..9b0bbc6f
Binary files /dev/null and b/blog/pics/aimsinvertercontrolschematic.jpg differ

blog update
diff --git a/blog/entry/AIMS_inverter_control_via_GPIO_ports.mdwn b/blog/entry/AIMS_inverter_control_via_GPIO_ports.mdwn
new file mode 100644
index 00000000..31071ee5
--- /dev/null
+++ b/blog/entry/AIMS_inverter_control_via_GPIO_ports.mdwn
@@ -0,0 +1,45 @@
+I recently upgraded my inverter to a AIMS 1500 watt pure sine inverter
+(PWRI150024S). This is a decent inverter for the price, I hope.
+It seems reasonably efficient under load compared to other inverters. 
+But when it's fully idle, it still consumes 4 watts of power. 
+
+That's almost as much power as my laptop, and while 96 watt-hours per day 
+may not sound like a lot of power, some days in winter, 100 watt-hours is
+my entire budget for the day. Adding more batteries just to power an idle
+inverter would be the normal solution, probably. Instead, I want to have my
+house computer turn it off when it's not being used.
+
+Which comes to the other problem with this inverter, since the power
+control is not a throw switch, but a button you have to press and hold for
+a second. And looking inside the inverter, this was not easily hacked to
+add a relay to control it.
+
+The inverter has a RJ22 control port. AIMS also does not seem to document
+what the pins do, so I reverse engineered them.
+
+Since the power is toggled, it's important that the computer be able to
+check if the inverter is currently running, to reliably get to the desired
+on/off state.
+
+I designed (well, mostly cargo-culted) a circuit that uses 4n35
+optoisolators to safely interface the AIMS with my cubietruck's GPIO ports,
+letting it turn the inverter on and off, and also check if it's currently
+running. Built this board, which is the first PCB I've designed and built
+myself.
+
+[[!img pics/aimsinvertercontrol.jpg size=640x]]
+[[!img pics/aimsinvertercontrolschematic.jpg]]
+
+The full schematic and haskell code to control the inverter are in
+the git repository <https://git.joeyh.name/index.cgi/joey/homepower.git/tree/>.
+My design notebook for this build is [available in secure scuttlebutt](https://viewer.scuttlebot.io/%25EvpWKGJyYIuSiOr3WjDsBCVHLIkt5Ncqd7lBsLX%2B9bs%3D.sha256)
+along with [power consumption measurements](https://viewer.scuttlebot.io/%25lPj7KktYPERL4N3WpF64UXFjcj19mDpt5F1YVblYi2k%3D.sha256).
+
+It works!
+
+	joey@darkstar:~>ssh house inverter status
+	off
+	joey@darkstar:~>ssh house inverter on
+	joey@darkstar:~>ssh house inverter status
+	on
+
diff --git a/blog/pics/aimsinvertercontrol.jpg b/blog/pics/aimsinvertercontrol.jpg
new file mode 100644
index 00000000..4ea4d086
Binary files /dev/null and b/blog/pics/aimsinvertercontrol.jpg differ

add talk
diff --git a/talks.mdwn b/talks.mdwn
index d0c2d0e8..aa770a1a 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -115,3 +115,8 @@ by others.
   - [[slides|debconf-17-life-after-debian.pdf]]
   - Correction: The other propellor developer in the audience of this talk,
     who I referred to as "Simon", was actually Sean Whitton.
+
+## Libreplanet 2017, MIT
+
+* "Secure Scuttlebutt lightning talk"
+  - [video](https://downloads.kitenet.net/talks/secure-scuttlebutt-lightning-talk-libreplanet.webm)

meh
diff --git a/blog/entry/three_conferences_one_week.mdwn b/blog/entry/three_conferences_one_week.mdwn
index 610f778c..ca683203 100644
--- a/blog/entry/three_conferences_one_week.mdwn
+++ b/blog/entry/three_conferences_one_week.mdwn
@@ -34,4 +34,4 @@ visit with me and go to a FP conference too.
 
 And now time to retreat into my retreaty place for a good long while.
 
-[[!img pics/springleaves.jpg size=1024x]]
+[[!img pics/springleaves.jpg size=764x]]

meh
diff --git a/blog/entry/three_conferences_one_week.mdwn b/blog/entry/three_conferences_one_week.mdwn
index 11fe707c..610f778c 100644
--- a/blog/entry/three_conferences_one_week.mdwn
+++ b/blog/entry/three_conferences_one_week.mdwn
@@ -34,4 +34,4 @@ visit with me and go to a FP conference too.
 
 And now time to retreat into my retreaty place for a good long while.
 
-[[!img size=1024x pics/springleaves.jpg]]
+[[!img pics/springleaves.jpg size=1024x]]

scale
diff --git a/blog/entry/three_conferences_one_week.mdwn b/blog/entry/three_conferences_one_week.mdwn
index 2387e771..11fe707c 100644
--- a/blog/entry/three_conferences_one_week.mdwn
+++ b/blog/entry/three_conferences_one_week.mdwn
@@ -34,4 +34,4 @@ visit with me and go to a FP conference too.
 
 And now time to retreat into my retreaty place for a good long while.
 
-[[!img pics/springleaves.jpg]]
+[[!img size=1024x pics/springleaves.jpg]]

pic
diff --git a/blog/entry/three_conferences_one_week.mdwn b/blog/entry/three_conferences_one_week.mdwn
index fa817052..2387e771 100644
--- a/blog/entry/three_conferences_one_week.mdwn
+++ b/blog/entry/three_conferences_one_week.mdwn
@@ -33,3 +33,5 @@ another Lambda Squared next year, and this might be a good opportunity to
 visit with me and go to a FP conference too.
 
 And now time to retreat into my retreaty place for a good long while.
+
+[[!img pics/springleaves.jpg]]
diff --git a/blog/pics/springleaves.jpg b/blog/pics/springleaves.jpg
new file mode 100644
index 00000000..b7f43e85
Binary files /dev/null and b/blog/pics/springleaves.jpg differ

post
diff --git a/blog/entry/three_conferences_one_week.mdwn b/blog/entry/three_conferences_one_week.mdwn
index 05acb54f..fa817052 100644
--- a/blog/entry/three_conferences_one_week.mdwn
+++ b/blog/entry/three_conferences_one_week.mdwn
@@ -1,34 +1,35 @@
 Thought I'd pack my entire year's conference schedule into one week...
 
-First was a Neuroinformatics infrastructure interoperability workshop at
-McGill, my second trip to Montreal this year. Well outside my wheelhouse,
-but there's a fair amount of interest in that community in git-annex/datalad.
-This was a roll with the acronyms, and try to draw parallels to things I know
-affair. Also excellent sushi and a bonus Secure Scuttlebutt meetup.
+First was a [Neuroinformatics infrastructure interoperability
+workshop](https://www.incf.org/node/272) at McGill, my second trip to
+Montreal this year. Well outside my wheelhouse, but there's a fair amount
+of interest in that community in git-annex/datalad. This was a roll with
+the acronyms, and try to draw parallels to things I know affair. Also
+excellent sushi and a bonus Secure Scuttlebutt meetup.
 
-Then LibrePlanet. A unique and super special conference, that utterly flew
-by this year. This is my sixth LibrePlanet and I enjoy it more each time.
-Hghlights for me were Bassam's photogrammetry workshop, Karen receiving
-the Free Software award, and Seth's thought-provoking talk on
-"incompossibilities". And some epic dinner conversations.
+Then [LibrePlanet](https://libreplanet.org/2018). A unique and super special
+conference, that utterly flew by this year. This is my sixth LibrePlanet
+and I enjoy it more each time. Hghlights for me were Bassam's
+photogrammetry workshop, Karen receiving the Free Software award, and
+Seth's thought-provoking talk on "incompossibilities" especially as applied
+to social networks. And some epic dinner conversations in central square.
 
-Finally today, a one-day localish(!) functional programming(!!) conference
-in Knoxville TN. Lambda Squared was the best constructed single-track
-conference I've seen. Starting with an ex-pro-figure skater getting the
-whole audience to pirouette to capture that uncomfortable out of your
-element feeling you get learning FP, and ramping gradually past "functional
-javascript" to orthagonality, cofunctors, the type system cube, and
-constructionalism.
+Finally today, a one-day local(!) functional programming(!!) conference
+in Knoxville TN. [Lambda Squared](https://www.lambda-squared.com/schedule)
+was the best constructed single-track conference I've seen. Starting with
+an ex-pro-figure skater getting the [whole audience to
+pirouette](https://twitter.com/Aimee_Knight/status/979772267487023104) to
+capture that uncomfortable out of your element feeling you get learning FP,
+and ramping gradually past "functional javascript" to orthagonality,
+contravariant functors, the lambda cube, and constructivist logic.
 
-There are not a lot of functional programming conferences in the
-southeastern USA, and I think this explains how Lambda Squared attracted
-such a good lineup of speakers. Also Knoxville has a surprisingly large and
-lively FP community forming, which has been a surprise to me as I never get
-over there. There will be another Lambda Squared next year, and this
-might be a good opportunity to visit with me and go to a FP conference too.
-
-(Also I finally managed to talk to a geologist about entropy and rocks. At
-the FP conference of all places. I want to talk to more geologists about
-entropy and rocks. The reason is obvious I assume...)
+I notice that I've spent a lot more time in Boston than I ever have in
+Knoxville -- Cambridge MA is starting to feel like my old haunts, though
+I've never really lived there. There are not a lot of functional
+programming conferences in the southeastern USA, and I think this explains
+how Lambda Squared attracted such a good lineup of speakers. Also Knoxville
+has a surprisingly large and lively FP community shaping up. There will be
+another Lambda Squared next year, and this might be a good opportunity to
+visit with me and go to a FP conference too.
 
 And now time to retreat into my retreaty place for a good long while.

blog update
diff --git a/blog/entry/three_conferences_one_week.mdwn b/blog/entry/three_conferences_one_week.mdwn
new file mode 100644
index 00000000..05acb54f
--- /dev/null
+++ b/blog/entry/three_conferences_one_week.mdwn
@@ -0,0 +1,34 @@
+Thought I'd pack my entire year's conference schedule into one week...
+
+First was a Neuroinformatics infrastructure interoperability workshop at
+McGill, my second trip to Montreal this year. Well outside my wheelhouse,
+but there's a fair amount of interest in that community in git-annex/datalad.
+This was a roll with the acronyms, and try to draw parallels to things I know
+affair. Also excellent sushi and a bonus Secure Scuttlebutt meetup.
+
+Then LibrePlanet. A unique and super special conference, that utterly flew
+by this year. This is my sixth LibrePlanet and I enjoy it more each time.
+Hghlights for me were Bassam's photogrammetry workshop, Karen receiving
+the Free Software award, and Seth's thought-provoking talk on
+"incompossibilities". And some epic dinner conversations.
+
+Finally today, a one-day localish(!) functional programming(!!) conference
+in Knoxville TN. Lambda Squared was the best constructed single-track
+conference I've seen. Starting with an ex-pro-figure skater getting the
+whole audience to pirouette to capture that uncomfortable out of your
+element feeling you get learning FP, and ramping gradually past "functional
+javascript" to orthagonality, cofunctors, the type system cube, and
+constructionalism.
+
+There are not a lot of functional programming conferences in the
+southeastern USA, and I think this explains how Lambda Squared attracted
+such a good lineup of speakers. Also Knoxville has a surprisingly large and
+lively FP community forming, which has been a surprise to me as I never get
+over there. There will be another Lambda Squared next year, and this
+might be a good opportunity to visit with me and go to a FP conference too.
+
+(Also I finally managed to talk to a geologist about entropy and rocks. At
+the FP conference of all places. I want to talk to more geologists about
+entropy and rocks. The reason is obvious I assume...)
+
+And now time to retreat into my retreaty place for a good long while.

fixup: forgot signature
diff --git a/code/moreutils/discussion.mdwn b/code/moreutils/discussion.mdwn
index ac56507b..d54ca26b 100644
--- a/code/moreutils/discussion.mdwn
+++ b/code/moreutils/discussion.mdwn
@@ -16,6 +16,8 @@ I'm running "chronic fetchmail" in my crontab and I'd like to discard exit code
 The method proposed in fetchmail's man page is to run "chronic sh -c 'fetchmail || [ $? -eq 1 ]'" but I'd prefer something like "chronic -i 1 fetchmail", because this avoids the separate shell and allows to discard several exit codes (think of rsync's various possibly unimportant errors).
 I'll try to come up with a patch if this is desired.
 
+-- deep42thought
+
 ### triggering with zero exit code
 
 I've a use case where I want chronic to work in exactly the opposite fashion: to throw away stdout/stderr if and only if the exit code is non-zero. I could obviously do this with a wrapper script that inverts the exit code, but that (a) means I only know whether the command I ran had a zero/non-zero exit code, not what it was, and (b) means there's an unnecessary layer between chronic and the command.

proposal: chronic: ignore (selected) non-zero exit codes
diff --git a/code/moreutils/discussion.mdwn b/code/moreutils/discussion.mdwn
index 5d34e00c..ac56507b 100644
--- a/code/moreutils/discussion.mdwn
+++ b/code/moreutils/discussion.mdwn
@@ -10,6 +10,12 @@ It put it up on [github here](https://github.com/girst/forkaftergrep)
 
 ## chronic
 
+### discarding certain non-zero exit codes
+
+I'm running "chronic fetchmail" in my crontab and I'd like to discard exit code 1 - "no new mail".
+The method proposed in fetchmail's man page is to run "chronic sh -c 'fetchmail || [ $? -eq 1 ]'" but I'd prefer something like "chronic -i 1 fetchmail", because this avoids the separate shell and allows to discard several exit codes (think of rsync's various possibly unimportant errors).
+I'll try to come up with a patch if this is desired.
+
 ### triggering with zero exit code
 
 I've a use case where I want chronic to work in exactly the opposite fashion: to throw away stdout/stderr if and only if the exit code is non-zero. I could obviously do this with a wrapper script that inverts the exit code, but that (a) means I only know whether the command I ran had a zero/non-zero exit code, not what it was, and (b) means there's an unnecessary layer between chronic and the command.

Added a comment: ethics and open source
diff --git a/blog/entry/prove_you_are_not_an_Evil_corporate_person/comment_3_aae1b5869c77a78bdddc14bf8f754e4c._comment b/blog/entry/prove_you_are_not_an_Evil_corporate_person/comment_3_aae1b5869c77a78bdddc14bf8f754e4c._comment
new file mode 100644
index 00000000..a9c4edc0
--- /dev/null
+++ b/blog/entry/prove_you_are_not_an_Evil_corporate_person/comment_3_aae1b5869c77a78bdddc14bf8f754e4c._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="paolo.greppi@1e21b72a79d4a7d7ea51729cfb52e8d00557ccd4"
+ nickname="paolo.greppi"
+ avatar="http://cdn.libravatar.org/avatar/068b9627eda3ed0b35fecd432dcac210"
+ subject="ethics and open source"
+ date="2018-03-14T18:57:05Z"
+ content="""
+Google Inc may be opposed to AGPL but other interested parties may well happily take it.
+
+I think you are misusing an open source license to achieve an **ethical purpose**.
+
+If you want to be 100% sure that your open source work is not used for “*evil*” you could add to the license the line \"*The Software shall be used for Good, not Evil*\" (see [JSLint](https://en.wikipedia.org/wiki/JSLint#License)).
+
+But then who checks what is \"*evil*\"?
+
+You probably need to set up a bureaucracy with \"*certificates*\" issued by independent third partes do demonstrate that the purpose is \"*not evil*\" (as you need if you want to sell \"*organic*\" food).
+"""]]

no
diff --git a/blog/entry/prove_you_are_not_an_Evil_corporate_person/comment_2_696cc0f17e5de956d048ebe0efe53592._comment b/blog/entry/prove_you_are_not_an_Evil_corporate_person/comment_2_696cc0f17e5de956d048ebe0efe53592._comment
new file mode 100644
index 00000000..3c9ccd8c
--- /dev/null
+++ b/blog/entry/prove_you_are_not_an_Evil_corporate_person/comment_2_696cc0f17e5de956d048ebe0efe53592._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: above kilobyte of nonsense"""
+ date="2018-03-13T14:36:45Z"
+ content="""
+The AGPL is a DFSG compliant license; all of my AGPL
+licensed software is in fact distributed in Debian.
+"""]]

Added a comment: DFSG#5 and #6
diff --git a/blog/entry/prove_you_are_not_an_Evil_corporate_person/comment_1_b17538f3c01328df7c1d9f6c7ed39ce3._comment b/blog/entry/prove_you_are_not_an_Evil_corporate_person/comment_1_b17538f3c01328df7c1d9f6c7ed39ce3._comment
new file mode 100644
index 00000000..a4f195e0
--- /dev/null
+++ b/blog/entry/prove_you_are_not_an_Evil_corporate_person/comment_1_b17538f3c01328df7c1d9f6c7ed39ce3._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="kilobyte@ae5b544234799453020139b13729c204af96255d"
+ nickname="kilobyte"
+ avatar="http://cdn.libravatar.org/avatar/df4ea9661bdbcda2f6c65ef48902645b"
+ subject="DFSG#5 and #6"
+ date="2018-03-12T22:58:29Z"
+ content="""
+This sounds like a very clear-cut violation of DFSG#5 and #6.  You're
+discriminating against using the software for military purposes.
+
+Well, this is the same Google that discriminates against anyone who's
+looking to purchase a gun or anything unrelated that just happens to have
+\"gun\" as part of a word in its name (yet something denying cakes for gay
+weddings is a legal argument used by them), but two wrongs don't make a
+right.
+
+There's also a question whether AGPL is a free software license at all.
+I believe it's not: fails FSF Freedom 0 (networked light switch; IMAP
+server) and the Dissident Test (a dissident hiding steganographic messages
+on a blogging platform with thousands of unrelated users; only fellow
+dissidents receive a module to encrypt/decrypt the messages).
+
+"""]]

avoid rescale
diff --git a/blog/entry/prove_you_are_not_an_Evil_corporate_person.mdwn b/blog/entry/prove_you_are_not_an_Evil_corporate_person.mdwn
index b32ad9e3..62f88287 100644
--- a/blog/entry/prove_you_are_not_an_Evil_corporate_person.mdwn
+++ b/blog/entry/prove_you_are_not_an_Evil_corporate_person.mdwn
@@ -1,6 +1,6 @@
 In which Google be Google and I drop a hot AGPL tip.
 
-[[!img pics/recaptcha.png]]
+[[pics/recaptcha.png]]
 
 [Google Is Quietly Providing AI Technology for Drone Strike Targeting Project](https://theintercept.com/2018/03/06/google-is-quietly-providing-ai-technology-for-drone-strike-targeting-project/)  
 [Google Is Helping the Pentagon Build AI for Drones](https://gizmodo.com/google-is-helping-the-pentagon-build-ai-for-drones-1823464533)

smaller
diff --git a/blog/pics/recaptcha.png b/blog/pics/recaptcha.png
index 4c1a40f0..f187c7d3 100644
Binary files a/blog/pics/recaptcha.png and b/blog/pics/recaptcha.png differ

blog update
diff --git a/blog/entry/prove_you_are_not_an_Evil_corporate_person.mdwn b/blog/entry/prove_you_are_not_an_Evil_corporate_person.mdwn
new file mode 100644
index 00000000..b32ad9e3
--- /dev/null
+++ b/blog/entry/prove_you_are_not_an_Evil_corporate_person.mdwn
@@ -0,0 +1,62 @@
+In which Google be Google and I drop a hot AGPL tip.
+
+[[!img pics/recaptcha.png]]
+
+[Google Is Quietly Providing AI Technology for Drone Strike Targeting Project](https://theintercept.com/2018/03/06/google-is-quietly-providing-ai-technology-for-drone-strike-targeting-project/)  
+[Google Is Helping the Pentagon Build AI for Drones](https://gizmodo.com/google-is-helping-the-pentagon-build-ai-for-drones-1823464533)
+
+> to automate the identification and classification of images taken
+> by drones — cars, buildings, people — providing analysts with increased
+> ability to make informed decisions on the battlefield
+
+These news reports don't mention reCaptcha explicitly, but it's been asking
+about a lot of cars lately. Whatever the source of the data that Google is
+using for this, it's disgusting that they're mining it from us without our
+knowledge or consent.
+
+Google claims that "The technology flags images for human review, and is
+for non-offensive uses only". So, if a drone operator has a neural network
+that we all were tricked & coerced into training to identify cars and
+people helping to highlight them on their screen and center the crosshairs
+just right, and the neural network is not pressing the kill switch, is it
+being used for "non-offensive purposes only"?
+
+---
+
+Google is known to be 
+[deathly allergic to the AGPL license](https://opensource.google.com/docs/using/agpl-policy/). 
+Not only on servers; they don't even allow employees to use AGPL
+software on workstations. If you write free software, and you'd prefer
+that Google not use it, a good way to ensure that is to license it
+under the AGPL.
+
+I normally try to respect the privacy of users of my software, and of
+personal conversations. But at this point, I feel that
+Google's behavior has mostly obviated those moral obligations. So...
+
+Now seems like a good time to mention that I have been contacted by
+multiple people at Google about several of my AGPL licensed projects
+(git-annex and either keysafe or debug-me I can't remember which)
+trying to get me to switch them to the GPL, and had long conversations with
+them about it.
+
+Google has some legal advice that the AGPL source provision triggers much
+more often than it's commonly understood to. I encouraged them to make that
+legal reasoning public, so the community could address/debunk it, but I
+don't think they have. I won't go into details about it here, other than it
+seemed pretty bonkers.
+
+Mixing in some AGPL code with an otherwise GPL codebase also seems
+sufficient to trigger Google's allergy. In the case of git-annex, it's
+possible to build all releases (until next month's) with a flag that prevents
+linking with any AGPL code, which should mean the resulting binary is GPL
+licensed, but Google still didn't feel able to use it, since the git-annex
+source tree includes AGPL files.
+
+I don't know if Google's allergy to the AGPL extends to software used for
+drone murder applications, but in any case I look forward to preventing
+Google from using more of my software in the future.
+
+---
+
+(Illustration by [scatter//gather](https://freeradical.zone/@scattergather))
diff --git a/blog/pics/recaptcha.png b/blog/pics/recaptcha.png
new file mode 100644
index 00000000..4c1a40f0
Binary files /dev/null and b/blog/pics/recaptcha.png differ

Added a comment: Popularity of Nix*
diff --git a/blog/entry/futures_of_distributions/comment_2_522940371f18b0596744f90ffb65c4ee._comment b/blog/entry/futures_of_distributions/comment_2_522940371f18b0596744f90ffb65c4ee._comment
new file mode 100644
index 00000000..ea93d8f1
--- /dev/null
+++ b/blog/entry/futures_of_distributions/comment_2_522940371f18b0596744f90ffb65c4ee._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="vcunat@521cb015cc4d33a7a88cbb5280ae73e1c6b334aa"
+ nickname="vcunat"
+ avatar="http://cdn.libravatar.org/avatar/25b729764c1d24d94246e3243865b2a2"
+ subject="Popularity of Nix*"
+ date="2018-02-25T10:53:19Z"
+ content="""
+I believe the popularity of NixPkgs has multiplied over the past few years, e.g. look at [\"contributors per month\"](https://www.openhub.net/p/nixos/contributors/summary) (60 -> 250 in the past four years).  That shows rapid growth of the number of people who \"only\" send a few changes (per month), which is IMHO a plausible indication of being an common active user.
+
+I actually think that too rapid growth would be detrimental, as quite some things need to change in the organization of such a project to handle the growth (e.g. just manpower for issues and PRs), and such changes tend work better if given sufficient time.
+
+BTW, NixPkgs also strives to only have one version per package, except for cases with good-enough reason to do otherwise.  It really helps maintenance, debugging, etc.  So it's a kind of strange situation: technically Nix makes multiple versions easier, but tries to avoid using this :-)
+"""]]

Added a comment: Versions
diff --git a/blog/entry/futures_of_distributions/comment_1_16c994dc805c410f7580de95bdae6579._comment b/blog/entry/futures_of_distributions/comment_1_16c994dc805c410f7580de95bdae6579._comment
new file mode 100644
index 00000000..6c0203f6
--- /dev/null
+++ b/blog/entry/futures_of_distributions/comment_1_16c994dc805c410f7580de95bdae6579._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/80668afb-c026-4783-8ab2-662719b48a21"
+ nickname="tomi"
+ avatar="http://cdn.libravatar.org/avatar/dd5752cff8689312f614f35f16961e8d5c22677fbf68bfb7b7dd7145551b5861"
+ subject="Versions"
+ date="2018-02-18T13:06:38Z"
+ content="""
+> Debian still only packages one version of anything
+
+One of the killer features of Debian is that it does _not_ just package one version of anything. C libraries are usually packaged so that the package name contains soname version, so that multiple versions are coinstallable and dependencies just work. When things break (and they do), it's usually easy to keep an old version for years while the rest of the system is updated regularly. This usually applies to libs only, not their -dev packages, but sometimes there are multiple versions of those as well, and even non-libraries, e.g python3.5 & python3.6. Obviously this increases maintenance costs, but from an end user (me) point of view, it's absolutely worth it. (Thanks to everyone involved!)
+
+Now for Haskell this a bit more difficult because of code inlining. To make things coinstallable, I'd suggest reversing the current package namimg practice: instead of having \"libghc-mtl-dev\" as name and \"libghc-mtl-dev-2.2.1-93d32\" as Provides, do it the other way round. Perhaps even \"libghc8.0-mtl-dev-...\" Admittedly this would poison the package namespace and slow apt down considerably. Also, unless it's all automated, the manual labor needed to maintain multiple versions of everything would be unbearable.
+
+I guess if there was an apt repository that contained such packages and I could ask it to install from a specific version of Stackage LTS, I'd use it instead of stack immediately. I'm quite annoyed by stack's ignorance of disk space. As if these young people never ever had to uninstall anything.
+"""]]

blog update
diff --git a/blog/entry/futures_of_distributions.mdwn b/blog/entry/futures_of_distributions.mdwn
new file mode 100644
index 00000000..b88c9fb8
--- /dev/null
+++ b/blog/entry/futures_of_distributions.mdwn
@@ -0,0 +1,81 @@
+Seems Debian is talking about why they are unable to package whole
+categories of modern software, such as anything using npm. It's good
+they're having a conversation about that, and I want to give a
+broader perspective.
+
+Lars Wirzenius's 
+[blog post](http://blog.liw.fi/posts/2018/02/17/what_is_debian_all_about_really_or_friction_packaging_complex_applications/)
+about it explains the problem well from the Debian perspective. In short:
+The granularity at which software is built has fundamentally changed. It's
+now typical for hundreds of small libraries to be used by any application,
+often pegged to specific versions. Language-specific tools manage all the
+resulting complexity automatically, but distributions can't muster the
+manpower to package a fraction of this stuff.
+
+Lars lists some ideas for incremental improvements, but the space 
+within which a Linux distribution exists has changed, and that calls
+not for incremental changes, but for a fundamental rethink from the ground
+up. Whether Debian is capable of making such fundamental changes at this
+point in its lifecycle is up to its developers to decide.
+
+Perhaps other distributions are dealing with the problem better?
+One way to evaluate this is to look at how a given programming language
+community feels about a distribution's handling of their libraries. Do they
+generally see the distribution as a road block that must be worked around,
+or is the distribution a useful part of their workflow? Do they want their
+stuff included in the distribution, or does that seem like a lot of
+pointless bother?
+
+I can only speak about the Haskell community. While there are some
+exceptions, it generally is not interested in Debian containing Haskell
+packages, and indeed system-wide installations of Haskell packages can be
+an active problem for development. This is despite Debian having done a
+much better job at packaging a lot of Haskell libraries than it has at say,
+npm libraries. Debian still only packages one version of anything, and
+there is lag and complex process involved, and so friction with the
+Haskell community.
+
+On the other hand, there is a distribution that the Haskell community
+broadly does like, and that's [Nix](https://nixos.org/). A subset of the
+Haskell community uses Nix to manage and deploy Haskell software, and
+there's generally a good impression of it. Nix seems to be doing something
+right, that Debian is not doing.
+
+It seems that Nix also has pretty good support for working with npm
+packages, including ingesting a whole dependency chain into the package
+manager with a [single command](https://github.com/svanderburg/node2nix), and 
+[thousands of npm libraries included in the distribution](https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/node-packages)
+I don't know how the npm community feels about Nix, but my guess is they
+like it better than Debian.
+
+Nix is a radical rethink of the distribution model. And it's jettisoned a
+lot of things that Debian does, like manually packaging software, or
+extreme license vetting. It's interesting that Guix, which
+uses the same technologies as Nix, but seems in many ways more Debian-like
+with its care about licensing etc, has also been 
+[unable to manage npm packaging](http://dustycloud.org/blog/javascript-packaging-dystopia/).
+This suggests to me that at least some of the things that Nix has
+jettisoned *need* to be jettisoned in order to succeed in the new distribution
+space.
+
+But. Nix is not really exploding in popularity from what I can see.
+It seems to have settled into a niche of its own, and is perhaps
+expanding here and there, but not rapidly. It's insignificant compared
+with things like Docker, that also radically rethink the distribution model.
+
+We could easily end up with some nightmare of lithification, as
+described by Robert "r0ml" Lefkowitz in
+[his Linux.conf.au talk](https://lwn.net/Articles/712376/).
+Endlessly copied and compacted layers of code, contained or in the cloud.
+Programmer-archeologists right out of a Vinge SF novel.
+
+r0ml suggests that we assume that's where things are going (or indeed where
+they already are outside little hermetic worlds like Debian), and focus on
+solving technical problems, like deployment of modifications of cloud apps,
+that prevent users from exercising software freedoms.
+
+In a way, r0ml's ideas are what led me to thinking about
+[[extending_Scuttlebutt_with_Annah]], and indeed if you squint at that
+right, it's an idea for a radically different kind of distribution.
+
+Well, that's all I have. No answers of course.

update
diff --git a/rfc/rel-vcs.mdwn b/rfc/rel-vcs.mdwn
index 42dc5a41..284ed960 100644
--- a/rfc/rel-vcs.mdwn
+++ b/rfc/rel-vcs.mdwn
@@ -80,12 +80,15 @@ repository being browsed.
 
 * [gitweb patch](http://article.gmane.org/gmane.comp.version-control.git/104848)
 
-A web site that is itself stored in a VCS repository can include the
-`rel=vcs-*` microformat on its pages to indicate the location of the
-repository.
+  A web site that is itself stored in a VCS repository can include the
+  `rel=vcs-*` microformat on its pages to indicate the location of the
+  repository.
 
 * [ikiwiki repolist plugin](http://ikiwiki.info/plugins/repolist)
 
+* [Debian's package tracker](https://tracker.debian.org/) uses it to
+  indicate the VCS of packages.
+
 * [Request for support in launchpad](https://bugs.launchpad.net/launchpad-code/+bug/413130)
 
 ## Consumers

update
diff --git a/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn b/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn
index 7a6b2a24..ee6741a4 100644
--- a/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn
+++ b/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn
@@ -5,6 +5,8 @@ Hobart, Tasmania. [Abstract](https://linux.conf.au/schedule/presentation/116/)
 Linux.Conf.Au is a wonderful conference, and I'm thrilled to be able to
 attend it again.
 
+Update: LWN wrote up the talk here <https://lwn.net/Articles/713653/>
+
 [[!tag propellor]]
 
 --

blog update
diff --git a/blog/entry/easy-peasy-devicetree-squeezy.mdwn b/blog/entry/easy-peasy-devicetree-squeezy.mdwn
new file mode 100644
index 00000000..634aeef1
--- /dev/null
+++ b/blog/entry/easy-peasy-devicetree-squeezy.mdwn
@@ -0,0 +1,64 @@
+I've created a new program, with a silly name, that solves a silly problem
+with devicetree overlays. Seem that, alhough there's patches to fully
+support overlays, including loading them on the fly into a running system,
+it's not in the mainline kernel, and nobody seems to know if/when it will
+get mainlined.
+
+So easy-peasy-devicetree-squeezy is a hack to make it easy to do device tree
+overlay type things already. This program makes it easy peasy to squeeze
+together the devicetree for your board with whatever additions you need. It's
+pre-deprecated on release; as soon as device tree overlay support lands,
+there will be no further need for it, probably.
+
+It doesn't actually use overlays, instead it arranges to include the kernel's
+devicetree file for your board together with whatever additions you need. The
+only real downside of this approach is that the kernel source tarball is
+needed. Benefits include being able to refer to any labels you need from the
+kernel's devicetree files, and being able to #include and use symbols like
+`GPIO_ACTIVE_HIGH` from the kernel headers.
+
+It supports integrating into a Debian system so that the devicetree will
+be updated, with your additions, whenever the kernel is upgraded.
+
+Source is in a git repository at
+<https://git.joeyh.name/index.cgi/easy-peasy-devicetree-squeezy.git/>  
+See the [README](https://git.joeyh.name/index.cgi/easy-peasy-devicetree-squeezy.git/tree/README.md)
+for details.
+
+If someone wants to package this up and include it in Debian, it's a simple
+shell script, so it should take about 10 minutes.
+
+## example use
+
+Earlier I wrote about [[cubietruck_temperature_sensor]] setup, 
+and the difficulty I had with modifying the device tree for that. 
+With easy-peasy-devicetree-squeezy, I only have to create a file
+/etc/easy-peasy-devicetree-squeezy/my.dts that contains
+this:
+
+        /* Device tree addition enabling onewire sensors
+         * on CubieTruck GPIO pin PG8 */
+        #include <dt-bindings/gpio/gpio.h>
+
+        / {
+                onewire_device {
+                        compatible = "w1-gpio";
+                        gpios = <&pio 6 8 GPIO_ACTIVE_HIGH>; /* PG8 */
+                        pinctrl-names = "default";
+                        pinctrl-0 = <&my_w1_pin>;
+                };
+        };
+
+        &pio {
+                my_w1_pin: my_w1_pin@0 {
+                        allwinner,pins = "PG8";
+                        allwinner,function = "gpio_in";
+                };
+        };
+
+Then run "sudo easy-peasy-devicetree-squeezy --debian sun7i-a20-cubietruck"
+
+[[!img pics/lemontree.jpg]]
+
+Today's work was sponsored by Trenton Cronholm on
+[Patreon](https://patreon.com/joeyh/).
diff --git a/code.mdwn b/code.mdwn
index 6eee33d1..38a0f9ee 100644
--- a/code.mdwn
+++ b/code.mdwn
@@ -18,6 +18,7 @@ The stuff that's swapped into my local cache at the moment.
 [[github-backup]]
 [[shell-monad]]
 [[scuttlebutt-types]]
+[[easy-peasy-devicetree-squeezy]]
 
 ## Less active projects
 
diff --git a/code/easy-peasy-devicetree-squeezy.mdwn b/code/easy-peasy-devicetree-squeezy.mdwn
new file mode 100644
index 00000000..370334f2
--- /dev/null
+++ b/code/easy-peasy-devicetree-squeezy.mdwn
@@ -0,0 +1,4 @@
+Little hack to work around device tree overlay support not being in
+mainline. <https://git.joeyh.name/index.cgi/easy-peasy-devicetree-squeezy.git/>
+
+[[Accouncement|blog/entry/easy-peasy-devicetree-squeezy]]

add
diff --git a/blog/pics/lemontree.jpg b/blog/pics/lemontree.jpg
new file mode 100644
index 00000000..0e39c303
Binary files /dev/null and b/blog/pics/lemontree.jpg differ

Added a comment: laptop-mode-tools or tlp
diff --git a/blog/entry/improving_powertop_autotuning/comment_5_b5cebfe89df77f724807856ed44ece7b._comment b/blog/entry/improving_powertop_autotuning/comment_5_b5cebfe89df77f724807856ed44ece7b._comment
new file mode 100644
index 00000000..8bdedc9a
--- /dev/null
+++ b/blog/entry/improving_powertop_autotuning/comment_5_b5cebfe89df77f724807856ed44ece7b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jasc@f9a7e6f8a586ee640465d684b4c55f604a6ba184"
+ nickname="jasc"
+ avatar="http://cdn.libravatar.org/avatar/9e2af3eb210334bedb4094a38146b56b"
+ subject="laptop-mode-tools or tlp"
+ date="2018-02-05T20:11:12Z"
+ content="""
+Isn't that what these packages attempt to do?
+"""]]

response
diff --git a/blog/entry/improving_powertop_autotuning/comment_4_22335cc40c2f627263e13e7215ecff93._comment b/blog/entry/improving_powertop_autotuning/comment_4_22335cc40c2f627263e13e7215ecff93._comment
new file mode 100644
index 00000000..2525bb71
--- /dev/null
+++ b/blog/entry/improving_powertop_autotuning/comment_4_22335cc40c2f627263e13e7215ecff93._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-02-03T13:32:07Z"
+ content="""
+@josh, the problem is that these tunings are not always safe to enable,
+causing audio problems or screen problems or whatever, and information
+about which laptops have hardware that breaks with them is currently hard
+to collect.
+
+But yes, if the information were collected as I propose, it could be used
+in the kernel to whitelist the tunings on good hardware.
+"""]]

Added a comment: Better defaults?
diff --git a/blog/entry/improving_powertop_autotuning/comment_3_024d30067e5048591845adef8aff81e8._comment b/blog/entry/improving_powertop_autotuning/comment_3_024d30067e5048591845adef8aff81e8._comment
new file mode 100644
index 00000000..294af229
--- /dev/null
+++ b/blog/entry/improving_powertop_autotuning/comment_3_024d30067e5048591845adef8aff81e8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="josh@ccccabe84317e1b7429fd465de0b38fd54925dea"
+ nickname="josh"
+ avatar="http://cdn.libravatar.org/avatar/1bd07f791d8ed5989a92790b0a1f9ea4"
+ subject="Better defaults?"
+ date="2018-02-03T08:45:02Z"
+ content="""
+Rather than making powertop auto-apply these settings, could we fix the default settings so that they match what powertop would set?
+"""]]

Added a comment: Config File
diff --git a/blog/entry/improving_powertop_autotuning/comment_2_f6f53ef12ea1639c94a319eae10970be._comment b/blog/entry/improving_powertop_autotuning/comment_2_f6f53ef12ea1639c94a319eae10970be._comment
new file mode 100644
index 00000000..2c34d357
--- /dev/null
+++ b/blog/entry/improving_powertop_autotuning/comment_2_f6f53ef12ea1639c94a319eae10970be._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="markus@e4871d230e27341de932403d424689d988951b6b"
+ nickname="markus"
+ avatar="http://cdn.libravatar.org/avatar/7d45a6602e83baea71d15d7a80b591a1"
+ subject="Config File"
+ date="2018-02-02T19:19:19Z"
+ content="""
+Of course we could invent a new config file format and we could write a new GUI for it.
+
+I think it would be wiser to use (and improve) solutions that already implement config
+file mechansims, have GUIs/WebUIs, and have ways to upload/share configs.
+
+Ad: More about that in the talk tomorrow at FOSDEM <https://fosdem.org/2018/schedule/event/elektra/>
+"""]]

Added a comment
diff --git a/blog/entry/improving_powertop_autotuning/comment_1_fc0b1ff5e549db9af965f434265b3e53._comment b/blog/entry/improving_powertop_autotuning/comment_1_fc0b1ff5e549db9af965f434265b3e53._comment
new file mode 100644
index 00000000..9343fe53
--- /dev/null
+++ b/blog/entry/improving_powertop_autotuning/comment_1_fc0b1ff5e549db9af965f434265b3e53._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="db48x"
+ avatar="http://cdn.libravatar.org/avatar/ad2688127feb555a92154b16d8eeb5d3"
+ subject="comment 1"
+ date="2018-02-02T16:38:00Z"
+ content="""
+Every so often I remember about powertop and that I haven't automated it yet. I'd be willing to help.
+"""]]

blog update
diff --git a/blog/entry/improving_powertop_autotuning.mdwn b/blog/entry/improving_powertop_autotuning.mdwn
new file mode 100644
index 00000000..e01c6d04
--- /dev/null
+++ b/blog/entry/improving_powertop_autotuning.mdwn
@@ -0,0 +1,34 @@
+I'm wondering about improving powertop's auto-tuning. Currently the
+situation is that, if you want to tune your laptop's power consumption, you
+can run powertop and turn on all the tunables and try it for a while to see
+if anything breaks. The breakage might be something subtle.
+
+Then after a while you reboot and your laptop is using too much power again
+until you remember to run powertop again. This happens a half dozen or so
+times. You then automate running `powertop --auto-tune` or individual
+tuning commands on boot, probably using instructions you find in the Arch
+wiki.
+
+Everyone has to do this separately, which is a lot of duplicated and rather
+technical effort for users, while developers are left with a lot of work
+to manually collect information, like Hans de Goede is
+[doing now for enabling PSR by default](https://hansdegoede.livejournal.com/18653.html).
+
+To improve this, powertop could come with a service file to start it
+on boot, read a config file, and apply tunings if enabled.
+
+There could be a simple GUI to configure it, where the user can report
+when it's causing a problem. In case the problem prevents booting, there
+would need to be a boot option that disables the autotuning too.
+
+When the user reports a problem, the GUI could optionally walk them through
+a bisection to find the problematic tuning, which would probably take only
+4 or so steps.
+
+Information could be uploaded, anonymously to a hardware tunings database.
+Developers could then use that to find and whitelist safe tunings. Powertop
+could also query that to avoid tunings that are known to cause problems on
+the laptop.
+
+I don't know if this is a new idea, but if it's not been tried before,
+it seems worth working on.

remove link spams
diff --git a/blog/entry/Spectre_question/comment_4_2c836142fb823359b606aa0a59caeb64._comment b/blog/entry/Spectre_question/comment_4_2c836142fb823359b606aa0a59caeb64._comment
deleted file mode 100644
index 11766e21..00000000
--- a/blog/entry/Spectre_question/comment_4_2c836142fb823359b606aa0a59caeb64._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="noahlucas079@f6200401824cad3eec436a991f145058d0bc5aeb"
- nickname="noahlucas079"
- avatar="http://cdn.libravatar.org/avatar/98ac2ef648d1134f1165d50453c5cf7e"
- subject="great"
- date="2018-01-23T11:09:54Z"
- content="""
-good post found here. <a href=\"https://google.com\">site</a>
-"""]]
diff --git a/blog/entry/version_numbers/comment_7_07215952904242520e1b42ef1d6ec78c._comment b/blog/entry/version_numbers/comment_7_07215952904242520e1b42ef1d6ec78c._comment
deleted file mode 100644
index 18971f8c..00000000
--- a/blog/entry/version_numbers/comment_7_07215952904242520e1b42ef1d6ec78c._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="noahlucas079@f6200401824cad3eec436a991f145058d0bc5aeb"
- nickname="noahlucas079"
- avatar="http://cdn.libravatar.org/avatar/98ac2ef648d1134f1165d50453c5cf7e"
- subject="comment 7"
- date="2018-01-23T11:13:46Z"
- content="""
-Good piece of information regarding version numbers found in this article. It's very rare to have this kind of information because very few people have proper knowledge about version number and author of this article is one of those people. Use of these numbers in advance level of math is very important. However, I want <a href=\"https://www.bestessayservicereviews.com/\">essay writing service scams</a> but this site have a lot of more posts for the learning of students.
-"""]]

Added a comment
diff --git a/blog/entry/version_numbers/comment_7_07215952904242520e1b42ef1d6ec78c._comment b/blog/entry/version_numbers/comment_7_07215952904242520e1b42ef1d6ec78c._comment
new file mode 100644
index 00000000..18971f8c
--- /dev/null
+++ b/blog/entry/version_numbers/comment_7_07215952904242520e1b42ef1d6ec78c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="noahlucas079@f6200401824cad3eec436a991f145058d0bc5aeb"
+ nickname="noahlucas079"
+ avatar="http://cdn.libravatar.org/avatar/98ac2ef648d1134f1165d50453c5cf7e"
+ subject="comment 7"
+ date="2018-01-23T11:13:46Z"
+ content="""
+Good piece of information regarding version numbers found in this article. It's very rare to have this kind of information because very few people have proper knowledge about version number and author of this article is one of those people. Use of these numbers in advance level of math is very important. However, I want <a href=\"https://www.bestessayservicereviews.com/\">essay writing service scams</a> but this site have a lot of more posts for the learning of students.
+"""]]

Added a comment: great
diff --git a/blog/entry/Spectre_question/comment_4_2c836142fb823359b606aa0a59caeb64._comment b/blog/entry/Spectre_question/comment_4_2c836142fb823359b606aa0a59caeb64._comment
new file mode 100644
index 00000000..11766e21
--- /dev/null
+++ b/blog/entry/Spectre_question/comment_4_2c836142fb823359b606aa0a59caeb64._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="noahlucas079@f6200401824cad3eec436a991f145058d0bc5aeb"
+ nickname="noahlucas079"
+ avatar="http://cdn.libravatar.org/avatar/98ac2ef648d1134f1165d50453c5cf7e"
+ subject="great"
+ date="2018-01-23T11:09:54Z"
+ content="""
+good post found here. <a href=\"https://google.com\">site</a>
+"""]]

blog update
diff --git a/blog/entry/cubietruck_temperature_sensor.mdwn b/blog/entry/cubietruck_temperature_sensor.mdwn
new file mode 100644
index 00000000..7e8e6faa
--- /dev/null
+++ b/blog/entry/cubietruck_temperature_sensor.mdwn
@@ -0,0 +1,119 @@
+I wanted to use 1-wire temperature sensors (DS18B20) with
+my Cubietruck board, running Debian. The 
+[only page I could find documenting this](https://www.krausmueller.de/en/2016/02/08/ds18b20-with-cubietruck/) 
+is for the sunxi kernel, not the mainline kernel Debian uses.
+After a couple of hours of research I got it working, so here goes.
+
+## wiring
+
+First you need to pick a GPIO pin to use for the 1-wire signal. The
+Cubietruck's GPIO pins are 
+[documented here](http://docs.cubieboard.org/a20-cubietruck_gpio_pin),
+and I chose to use pin PG8. Other pins should work as well, although
+I originally tried to use PB17 and could not get it to work for an unknown
+reason. I also tried to use PB18 but there was a conflict with something
+else trying to use that same pin. To find a free pin, 
+`cat /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins` and look for
+a line like: "pin 200 (PG8): (MUX UNCLAIMED) (GPIO UNCLAIMED)"
+
+Now wire the DS18B20 sensor up. With its flat side facing you,
+the left pin goes to ground, 
+the center pin to PG8 (or whatever GPIO pin you selected), and the
+right pin goes to 3.3V. Don't forget to connect the necessary
+4.7K ohm resistor between the center and right pins. 
+
+You can find plenty of videos showing how to wire up the DS18B20 on
+youtube, which typically also involve a quick config change to a Raspberry
+Pi running Raspbian to get it to see the sensor. With Debian it's
+unfortunately quite a lot more complicated, and so this blog post got kind
+of long.
+
+## configuration
+
+We need to get the kernel to enable the GPIO pin. This seems like a really
+easy thing, but this is where it gets really annoying and painful. 
+
+You have to edit the Cubietruck's device tree. So `apt-get source linux`
+and in there edit `arch/arm/boot/dts/sun7i-a20-cubietruck.dts`
+
+In the root section ('/'), near the top, add this:
+
+        onewire_device {
+           compatible = "w1-gpio";
+           gpios = <&pio 6 8 GPIO_ACTIVE_HIGH>; /* PG8 */
+           pinctrl-names = "default";
+           pinctrl-0 = <&my_w1_pin>;
+        };
+
+In the '&pio` section, add this:
+
+        my_w1_pin: my_w1_pin@0 {
+             allwinner,pins = "PG8";
+             allwinner,function = "gpio_in";
+        };
+
+Note that if you used a different pin than PG8 you'll need to change
+that. The "pio 6 8" means letter G, pin 8. The 6 is because G is the 7th
+letter of the alphabet. I don't know where this is documented; I reverse
+engineered it from another example. Why this can't be hex, or octal, or 
+symbolic names or anything sane, I don't know.
+
+Now you'll need to compile the dts file into a dtb file. One way is to
+configure the kernel and use its Makefile; I avoided that by 
+first `sudo apt-get install device-tree-compiler` and then running,
+in the top of the linux source tree:
+
+	cpp -nostdinc -I include -undef -x assembler-with-cpp \
+		./arch/arm/boot/dts/sun7i-a20-cubietruck.dts | \
+		dtc -O dtb -b 0 -o sun7i-a20-cubietruck.dtb -
+
+You'll need to install that into `/etc/flash-kernel/dtbs/sun7i-a20-cubietruck.dtb`
+on the cubietruck. Then run `flash-kernel` to finish installing it.
+
+## use
+
+Now reboot, and if all went well, it'll come up and the GPIO pin will
+finally be turned on:
+
+	# grep PG8 /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins
+	pin 200 (PG8): onewire_device 1c20800.pinctrl:200 function gpio_in group PG8
+
+And if you picked a GPIO pin that works and got the sensor wired up
+correctly, in `/sys/bus/w1/devices/` there should be a subdirectory for the
+sensor, using its unique ID. Here I have two sensors connected, which
+1-wire makes easy to do, just hang them all off the same wire.. er wires.
+
+	root@honeybee:/sys/bus/w1/devices> ls
+	28-000008290227@  28-000008645973@  w1_bus_master1@
+	root@honeybee:/sys/bus/w1/devices> cat *-*/w1_slave
+	f6 00 4b 46 7f ff 0a 10 d6 : crc=d6 YES
+	f6 00 4b 46 7f ff 0a 10 d6 t=15375
+	f6 00 4b 46 7f ff 0a 10 d6 : crc=d6 YES
+	f6 00 4b 46 7f ff 0a 10 d6 t=15375
+
+So, it's 15.37 Celsius in my house. 
+I need to go feed the fire, this took too long to get set up.
+
+## future work
+
+Are you done at this point? I fear not entirely, because what
+happens when there's a kernel upgrade? If the device tree has changed
+in some way in the new kernel, you might need to update the modified device
+tree file. Or it might not boot properly or not work in some way.
+
+With Raspbian, you don't need to modify the device tree. Instead it has
+support for device tree overlay files, which add some entries to the
+main device tree. The distribution includes a bunch of useful overlays,
+including one that enables GPIO pins. The Raspberry Pi's
+bootloader takes care of merging the main device tree and the selected
+overlays.
+
+There are u-boot patches to do such merging, or the merging could be done
+before reboot (by `flash-kernel` perhaps), but apparently Debian's
+device tree files are built without phandle based referencing needed for
+that to work. (See <http://elektranox.org/2017/05/0020-dt-overlays/>)
+
+There's also a kernel patch to let overlays be loaded on the fly using
+configfs. It seems to have been around for several years without
+being merged, for whatever reason, but would avoid this problem nicely if
+it ever did get merged.
diff --git a/boxen.mdwn b/boxen.mdwn
index 115afbfc..1c5a95a2 100644
--- a/boxen.mdwn
+++ b/boxen.mdwn
@@ -11,9 +11,9 @@ Machines marked with a {*} are in active use.
 Mostly mythical creatures.
 
 * [[darkstar]] {*}
-* [[gnu]] {*}
 * kiwi {*} (Anna's)
 * aquamiser2 {*} (Mark's)
+* peregrine {*} (Mom's)
 * [[kodama]]
 * [[phoenix]]
 * [[dragon]]

Suggest chronic inversion behaviour
diff --git a/code/moreutils/discussion.mdwn b/code/moreutils/discussion.mdwn
index 604a289a..5d34e00c 100644
--- a/code/moreutils/discussion.mdwn
+++ b/code/moreutils/discussion.mdwn
@@ -10,6 +10,14 @@ It put it up on [github here](https://github.com/girst/forkaftergrep)
 
 ## chronic
 
+### triggering with zero exit code
+
+I've a use case where I want chronic to work in exactly the opposite fashion: to throw away stdout/stderr if and only if the exit code is non-zero. I could obviously do this with a wrapper script that inverts the exit code, but that (a) means I only know whether the command I ran had a zero/non-zero exit code, not what it was, and (b) means there's an unnecessary layer between chronic and the command.
+
+I've a patch that achieves exactly this; what's the best way to send it in for you to look at?
+
+-- Adam
+
 ### 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.

Added a comment: Update blog to tell about debuerreotype
diff --git a/blog/entry/docker_run_debian/comment_2_1aa6fce0b33275d31da3993dfa85c9a2._comment b/blog/entry/docker_run_debian/comment_2_1aa6fce0b33275d31da3993dfa85c9a2._comment
new file mode 100644
index 00000000..da049125
--- /dev/null
+++ b/blog/entry/docker_run_debian/comment_2_1aa6fce0b33275d31da3993dfa85c9a2._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="otto@9fc5a888cd0679974456e7bcba19b76165e55959"
+ nickname="otto"
+ avatar="http://cdn.libravatar.org/avatar/f5de2f6fbfd4c81e67a371393760b19b"
+ subject="Update blog to tell about debuerreotype"
+ date="2018-01-09T11:57:30Z"
+ content="""
+Hello!
+
+Please update this blog post. Many sites seem to link to it. It did
+raise a valid concern at the time it was written. Things have changes
+since, however.
+
+Nowadays anybody can independently build the same Docker images as
+published under the so called official Docker Debian account thanks to
+the new build system using debuerreotype:
+https://github.com/debuerreotype/debuerreotype
+
+Also, as a side note, if you want to have Debian images that are
+slightly more optimized for Docker in an opinionated way, you might
+want to check out https://github.com/jgoerzen/docker-debian-base
+"""]]

comment
diff --git a/blog/entry/Spectre_question/comment_2_2c453e9fe354fee894b10984abb996f7._comment b/blog/entry/Spectre_question/comment_2_2c453e9fe354fee894b10984abb996f7._comment
new file mode 100644
index 00000000..93503ff4
--- /dev/null
+++ b/blog/entry/Spectre_question/comment_2_2c453e9fe354fee894b10984abb996f7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-01-06T15:42:45Z"
+ content="""
+@larry which is the approach being used in the browsers, but seems very
+hard to prevent timing information being available to native code.
+"""]]
diff --git a/blog/entry/Spectre_question/comment_3_b7c70438eaafaa84ad2ca8e5179dfcfa._comment b/blog/entry/Spectre_question/comment_3_b7c70438eaafaa84ad2ca8e5179dfcfa._comment
new file mode 100644
index 00000000..8452bc67
--- /dev/null
+++ b/blog/entry/Spectre_question/comment_3_b7c70438eaafaa84ad2ca8e5179dfcfa._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""kinda answered"""
+ date="2018-01-06T15:43:38Z"
+ content="""
+Had a chat with Sesse about ASLR.
+
+ASLR operates on a page basis, and with 4k pages that's why the lower bytes
+are zero. When mapping a program into memory, it's necessarily page aligned.
+
+It does seem that it would be *possible* for binaries have their code be
+offset by some fraction of a page, but it would have overhead. Somewhere
+between the overhead of copying the whole binary's content into memory
+and the overhead of (non-dynamic) linking. And no executable pages could be
+shared between processes if that were done.
+"""]]

Added a comment: Spectre mitigation
diff --git a/blog/entry/Spectre_question/comment_1_cf5ac508c65a6d9a0a79529871d79d15._comment b/blog/entry/Spectre_question/comment_1_cf5ac508c65a6d9a0a79529871d79d15._comment
new file mode 100644
index 00000000..660d4ee6
--- /dev/null
+++ b/blog/entry/Spectre_question/comment_1_cf5ac508c65a6d9a0a79529871d79d15._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="larry@72dfe4624f2d038ed631eff22785a50a9b5f849f"
+ nickname="larry"
+ avatar="http://cdn.libravatar.org/avatar/ff74e82b892a802ba41c7fcd64203eea"
+ subject="Spectre mitigation"
+ date="2018-01-06T03:24:10Z"
+ content="""
+My possibly naive perspective is that Spectre is one of a large class of weaknesses based on incomplete virtualization/abstraction of the CPU.  As others have pointed out, modern hardware emulates a simple abstract machine in terms of execution order and memory models, where the reality is actually quite different.  The key item that is _not_ abstracted is _time_.  All side channels I know of (including the ones on which the Spectre work depends) require access to high-resolution non-virtual time.  Take that away, reserve those high-res timers for privileged-mode only, and I think you'll find problems like this just disappear.
+"""]]

update
diff --git a/blog/entry/Spectre_question.mdwn b/blog/entry/Spectre_question.mdwn
index c8aff2c2..882ee20c 100644
--- a/blog/entry/Spectre_question.mdwn
+++ b/blog/entry/Spectre_question.mdwn
@@ -12,7 +12,8 @@ bad as buffer overflows for the rest of us.
 
 Also, so far the mitigations being developed for Spectre only cover branching,
 but the Spectre paper also suggests the attack can be used in the absence of
-branches to eg determine the contents of registers.
+branches to eg determine the contents of registers, as long as the attacker
+knows the address of suitable instructions to leverage.
 
 So I wonder if a broader mitigation can be developed, if only to provide
 some defense in depth from Spectre.

blog update
diff --git a/blog/entry/Spectre_question.mdwn b/blog/entry/Spectre_question.mdwn
new file mode 100644
index 00000000..c8aff2c2
--- /dev/null
+++ b/blog/entry/Spectre_question.mdwn
@@ -0,0 +1,43 @@
+Could ASLR be used to prevent the [Spectre attack](https://meltdownattack.com/)?
+
+The way Spectre mitigations are shaping up, it's going to require modification
+of every program that deals with sensitive data, inserting serialization
+instructions in the right places. Or programs can be compiled with
+all branch prediction disabled, with more of a speed hit.
+
+Either way, that's going to be piecemeal and error-prone.
+We'll be stuck with a new class of vulnerabilities for a long time. Perhaps
+good news for the security industry, but it's going to become as tediously
+bad as buffer overflows for the rest of us.
+
+Also, so far the mitigations being developed for Spectre only cover branching,
+but the Spectre paper also suggests the attack can be used in the absence of
+branches to eg determine the contents of registers.
+
+So I wonder if a broader mitigation can be developed, if only to provide
+some defense in depth from Spectre.
+
+The [paper on Spectre](https://spectreattack.com/spectre.pdf)
+has this to say about ASLR:
+
+> The algorithm that tracks and matches jump histories appears to use only
+> the low bits of the virtual address (which are further reduced by simple hash
+> function). As a result, an adversary does not need to be able to even execute
+> code at any of the memory addresses containing the victim’s branch instruction.
+> ASLR can also be compensated, since upper bits are ignored and bits 15..0 do
+> not appear to be randomized with ASLR in Win32 or Win64.
+
+I think ASLR on Linux also doesn't currently randomize those bits of the address; 
+`cat /proc/self/maps` shows the lower 3 bytes always 0.
+But, could it be made to randomize more of the address, and so guard
+against Spectre?
+
+(Then we'd only have to get all binaries built PIE, which is easily audited for
+and distributions are well on their way toward already. Indeed, most 
+executables on my laptop are already built PIE, with the notable exception
+of /bin/bash and all haskell programs.)
+
+I don't have an answer to this question, but am very curious about thoughts
+from anyone who knows about ASLR and low level CPU details. I have not been
+able to find any discussion of it aside from the above part of the Spectre
+paper.

fix doubled text
diff --git a/blog/entry/two_holiday_stories.mdwn b/blog/entry/two_holiday_stories.mdwn
index 639197ea..e5162e76 100644
--- a/blog/entry/two_holiday_stories.mdwn
+++ b/blog/entry/two_holiday_stories.mdwn
@@ -33,8 +33,7 @@ I checked some old notes to find the recovery seeds, and restored "hot wallet"
 and "cold wallet", not sure which was my public incoming wallet. 
 Neither was, and after some concerned scrambling, I found the gpg locked
 file in a hidden basement subdirectory that let me access my public incoming
-wallet, and in fact two people *had* reacted to Patreon by sending bitcoin to
-me.
+wallet.
 
 What of the other two wallets? "Hot wallet" was empty. But "cold wallet"
 turned out to be some long forgotten wallet, and yes, this is now a story

removed
diff --git a/blog/entry/two_holiday_stories/comment_6_6ddc88f66e0a1238a05c1b673c58ad98._comment b/blog/entry/two_holiday_stories/comment_6_6ddc88f66e0a1238a05c1b673c58ad98._comment
deleted file mode 100644
index 79fa4d98..00000000
--- a/blog/entry/two_holiday_stories/comment_6_6ddc88f66e0a1238a05c1b673c58ad98._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="joey@2062a980cdd09efad926ddc127d2b3ef841638a1"
- nickname="joey"
- avatar="http://cdn.libravatar.org/avatar/7aea85346a93c59c4ae829659e489d18"
- subject="comment 6"
- date="2018-01-04T22:13:24Z"
- content="""
-test
-"""]]