Recent changes to this wiki:

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
-"""]]

Added a comment
diff --git a/blog/entry/two_holiday_stories/comment_6_6ddc88f66e0a1238a05c1b673c58ad98._comment b/blog/entry/two_holiday_stories/comment_6_6ddc88f66e0a1238a05c1b673c58ad98._comment
new file mode 100644
index 00000000..79fa4d98
--- /dev/null
+++ b/blog/entry/two_holiday_stories/comment_6_6ddc88f66e0a1238a05c1b673c58ad98._comment
@@ -0,0 +1,9 @@
+[[!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
+"""]]

add mastadon
diff --git a/grep.mdwn b/grep.mdwn
index 07b72b42..7c2fb83d 100644
--- a/grep.mdwn
+++ b/grep.mdwn
@@ -9,4 +9,5 @@ List of feeds:
 
 * [[!aggregate expirecount=25 name="music" feedurl="http://libre.fm/rdf.php?fmt=rss&page=%2Fuser%2Fjoeyhess%2Frecent-tracks" url="http://libre.fm/user/joeyhess"]]
 * [[!aggregate expirecount=25 name="identi.ca posts" feedurl="https://tmp.joeyh.name/pump.atom" url="http://identi.ca/joeyh"]]
+* [[!aggregate expirecount=25 name="mastadon posts" feedurl="https://octodon.social/users/joeyh.atom" url="https://octodon.social/users/joeyh"]]
 * [[!aggregate expirecount=25 name="books" feedurl="http://www.goodreads.com/review/list_rss/2159448?key=afd7e8432b3f9e33edab442a7c94e95849af4527&shelf=currently-reading" url="http://www.goodreads.com/user/show/2159448"]]

comment
diff --git a/blog/entry/two_holiday_stories/comment_5_f7aec80d3416ddfc9d8f81081076be3a._comment b/blog/entry/two_holiday_stories/comment_5_f7aec80d3416ddfc9d8f81081076be3a._comment
new file mode 100644
index 00000000..e62ba231
--- /dev/null
+++ b/blog/entry/two_holiday_stories/comment_5_f7aec80d3416ddfc9d8f81081076be3a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-01-01T21:07:05Z"
+ content="""
+I've recently got a 2017 Lenovo Yoga 11 inch, which is actually a pretty
+sweet little netbook, fanless and light and a lot smaller than older 11
+inch screen computers.
+"""]]

Added a comment: FYI
diff --git a/blog/entry/propelling_disk_images/comment_3_751ce5ad8dc630108565e88158fe5cd3._comment b/blog/entry/propelling_disk_images/comment_3_751ce5ad8dc630108565e88158fe5cd3._comment
new file mode 100644
index 00000000..8a5edf74
--- /dev/null
+++ b/blog/entry/propelling_disk_images/comment_3_751ce5ad8dc630108565e88158fe5cd3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="stappers@eb96885816da287c29f6f699999434d532149234"
+ nickname="stappers"
+ avatar="http://cdn.libravatar.org/avatar/bf33450acf6fc2a17a8b4e6fc7749c65"
+ subject="FYI"
+ date="2018-01-01T18:51:57Z"
+ content="""
+There is post <http://joeyh.name/blog/entry/custom_ARM_disk_image_generation_with_propellor/>
+"""]]

Added a comment: development machine
diff --git a/blog/entry/two_holiday_stories/comment_4_f523ef13f640bc1b915a20e57e3ff044._comment b/blog/entry/two_holiday_stories/comment_4_f523ef13f640bc1b915a20e57e3ff044._comment
new file mode 100644
index 00000000..907a5875
--- /dev/null
+++ b/blog/entry/two_holiday_stories/comment_4_f523ef13f640bc1b915a20e57e3ff044._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="steven@05e3369919e5db7190433a473113817da78ae4a0"
+ nickname="steven"
+ avatar="http://cdn.libravatar.org/avatar/9fe6eecd0900f0e779711f091fec8b3b"
+ subject="development machine"
+ date="2018-01-01T11:31:07Z"
+ content="""
+Sorry that comment is off-topic for this post but I just found your interview at https://usesthis.com/interviews/joey.hess/. I was wondering what your current development set up is? Are you still using a little netbook?
+
+I currently use a recent MacBook Air to develop Haskell but it can be fairly slow. I've recently set up a Ubuntu-based server on GCE which is quite nice to use (preemptible i.e. cheap) and their network is _heaps_ faster than my network at home (ADSL2+). I'm unable to use local SSDs with preembible GCE instance and the performance of persistent SSDs isn't really as fast as I'd like. Therefore I'm considering buying a workstation (tower/server) to put on my local network with latest Intel i9, lots of ram (32/64G) and fast SSD(s), probably running linux or freebsd with ZFS but wondering if it might be overkill. I've gotten used to remoting-in (ssh) to my GCE server, so remoting in to a local workstation would present little problems, workflow-wise. I tend to use tmux and spacemacs (with intero). I like Atom and it's haskell-ide plugin but luckily I switched to Spacemacs a few months ago now. I still occasionally use Atom-Beta on my local MacBook and haven't tried X11 forwarding yet to see if that workflow would still be useable. I've got a bad back — from too much time crouched over a keyboard — and it's nice to be able to use a laptop (or network) as my primary interface to my workstation (or server-in-the-cloud) so that I can mix up my work environment i.e. stand up desk with large monitor, sit down desk (aka dining room table) or couch/sofa.
+
+Appreciate any advice!
+"""]]

calendar update
diff --git a/blog/archives/2018.mdwn b/blog/archives/2018.mdwn
new file mode 100644
index 00000000..f363bea1
--- /dev/null
+++ b/blog/archives/2018.mdwn
@@ -0,0 +1 @@
+[[!calendar type=year year=2018 pages="blog/entry/* and !*/Discussion"]]
diff --git a/blog/archives/2018/01.mdwn b/blog/archives/2018/01.mdwn
new file mode 100644
index 00000000..f3b85b60
--- /dev/null
+++ b/blog/archives/2018/01.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=01 year=2018 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(01) and creation_year(2018) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2018/02.mdwn b/blog/archives/2018/02.mdwn
new file mode 100644
index 00000000..7a25b975
--- /dev/null
+++ b/blog/archives/2018/02.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=02 year=2018 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(02) and creation_year(2018) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2018/03.mdwn b/blog/archives/2018/03.mdwn
new file mode 100644
index 00000000..b973c822
--- /dev/null
+++ b/blog/archives/2018/03.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=03 year=2018 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(03) and creation_year(2018) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2018/04.mdwn b/blog/archives/2018/04.mdwn
new file mode 100644
index 00000000..2d327052
--- /dev/null
+++ b/blog/archives/2018/04.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=04 year=2018 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(04) and creation_year(2018) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2018/05.mdwn b/blog/archives/2018/05.mdwn
new file mode 100644
index 00000000..d63a5f97
--- /dev/null
+++ b/blog/archives/2018/05.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=05 year=2018 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(05) and creation_year(2018) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2018/06.mdwn b/blog/archives/2018/06.mdwn
new file mode 100644
index 00000000..2ff19a8f
--- /dev/null
+++ b/blog/archives/2018/06.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=06 year=2018 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(06) and creation_year(2018) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2018/07.mdwn b/blog/archives/2018/07.mdwn
new file mode 100644
index 00000000..76c30b83
--- /dev/null
+++ b/blog/archives/2018/07.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=07 year=2018 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(07) and creation_year(2018) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2018/08.mdwn b/blog/archives/2018/08.mdwn
new file mode 100644
index 00000000..70ab4b48
--- /dev/null
+++ b/blog/archives/2018/08.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=08 year=2018 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(08) and creation_year(2018) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2018/09.mdwn b/blog/archives/2018/09.mdwn
new file mode 100644
index 00000000..c0574eae
--- /dev/null
+++ b/blog/archives/2018/09.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=09 year=2018 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(09) and creation_year(2018) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2018/10.mdwn b/blog/archives/2018/10.mdwn
new file mode 100644
index 00000000..1e00c19e
--- /dev/null
+++ b/blog/archives/2018/10.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=10 year=2018 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(10) and creation_year(2018) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2018/11.mdwn b/blog/archives/2018/11.mdwn
new file mode 100644
index 00000000..f0a982fd
--- /dev/null
+++ b/blog/archives/2018/11.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=11 year=2018 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(11) and creation_year(2018) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2018/12.mdwn b/blog/archives/2018/12.mdwn
new file mode 100644
index 00000000..a3327338
--- /dev/null
+++ b/blog/archives/2018/12.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=12 year=2018 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(12) and creation_year(2018) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]

add news item for moreutils 0.62
diff --git a/code/moreutils/news/version_0.57.mdwn b/code/moreutils/news/version_0.57.mdwn
deleted file mode 100644
index 55983db3..00000000
--- a/code/moreutils/news/version_0.57.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-moreutils 0.57 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Avoid using non-portable error() in ifdata, a portability reversion
-     introduced in 0.56."""]]
\ No newline at end of file
diff --git a/code/moreutils/news/version_0.62.mdwn b/code/moreutils/news/version_0.62.mdwn
new file mode 100644
index 00000000..a73ed226
--- /dev/null
+++ b/code/moreutils/news/version_0.62.mdwn
@@ -0,0 +1,16 @@
+moreutils 0.62 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * ts: Add -m option to use monotonic clock.
+     Thanks, Ben Leinweber
+   * ts: Added %.T format like %T but with hi-res.
+     Thanks, Matt Koscica
+   * pee: Ignore SIGPIPE and write errors caused by the command not
+     consuming all its input. Closes: #[697052](http://bugs.debian.org/697052)
+     Thanks, Ole Jørgen Brønner
+   * chronic: document return value semantics of -e option. Closes: #[867167](http://bugs.debian.org/867167)
+     Thanks, Daniel Shahaf
+   * vidir: reword man page to more explicit mention 'file' args.
+     Closes: #[885221](http://bugs.debian.org/885221)
+     Thanks, Daniel Shahaf
+   * pee: Don't buffer input, bringing behavior into line with tee.
+     Thanks, Sauerbeck Tilman"""]]
\ No newline at end of file

tag
diff --git a/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn b/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn
index ca3a9119..55a38959 100644
--- a/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn
+++ b/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn
@@ -55,3 +55,5 @@ a disk image built by propellor,
 I've been involved with building disk image for ARM boards for a long
 time -- it was part of my job for five years -- and this is the first time
 I've been entirely happy with the process.
+
+[[!tag propellor]]

Added a comment: beyond compile error
diff --git a/blog/entry/custom_ARM_disk_image_generation_with_propellor/comment_1_d351c9f6efd4d5199907a2e31c017c95._comment b/blog/entry/custom_ARM_disk_image_generation_with_propellor/comment_1_d351c9f6efd4d5199907a2e31c017c95._comment
new file mode 100644
index 00000000..ea2563e6
--- /dev/null
+++ b/blog/entry/custom_ARM_disk_image_generation_with_propellor/comment_1_d351c9f6efd4d5199907a2e31c017c95._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="stappers@eb96885816da287c29f6f699999434d532149234"
+ nickname="stappers"
+ avatar="http://cdn.libravatar.org/avatar/bf33450acf6fc2a17a8b4e6fc7749c65"
+ subject="beyond compile error"
+ date="2017-12-29T00:53:25Z"
+ content="""
+In an attempt to reproduce the generation of custom ARM images I did get compile errors.
+
+The errors said what to do. e.g. change `hasPassword` into `User.hasPassword`.
+
+This gives me a clean compile with  propellor version 5.1.0
+
+	lime :: Host
+	lime = host \"lime.example.net\" $ props
+	    & osDebian Unstable ARMHF
+	    & Machine.olimex_A10_OLinuXino_LIME
+	    & hasPartition (partition EXT4 `mountedAt` \"/\" `setSize` MegaBytes 8192)
+	    & User.hasPassword (User \"root\")
+	    & Ssh.installed
+	    & Ssh.permitRootLogin (Ssh.RootLogin True)
+
+
+Caveat: not tested on actual hardware
+
+"""]]

podcast
diff --git a/code/pdmenu/news/podcast.mdwn b/code/pdmenu/news/podcast.mdwn
new file mode 100644
index 00000000..c2c91777
--- /dev/null
+++ b/code/pdmenu/news/podcast.mdwn
@@ -0,0 +1,2 @@
+Hacker Public Radio podcast episode about pdmenu.
+<http://hackerpublicradio.org/eps.php?id=2443>

Added a comment
diff --git a/blog/entry/two_holiday_stories/comment_3_16ef664266f1db0c57fd43eb8fda48bb._comment b/blog/entry/two_holiday_stories/comment_3_16ef664266f1db0c57fd43eb8fda48bb._comment
new file mode 100644
index 00000000..e076d4b5
--- /dev/null
+++ b/blog/entry/two_holiday_stories/comment_3_16ef664266f1db0c57fd43eb8fda48bb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="rjc"
+ avatar="http://cdn.libravatar.org/avatar/4f50c208bdc8c08ef5bd7d7f5d80383f"
+ subject="comment 3"
+ date="2017-12-13T22:55:47Z"
+ content="""
+All seems good now - [https://blog.patreon.com/not-rolling-out-fees-change/](https://blog.patreon.com/not-rolling-out-fees-change/)
+
+P.S. Some of the login/auth methods don't work, namely: email (seems broken) and Verisign (PIP doesn't exist any more).
+"""]]

response
diff --git a/blog/entry/two_holiday_stories/comment_2_ca056666154a77fc55e325aa080075eb._comment b/blog/entry/two_holiday_stories/comment_2_ca056666154a77fc55e325aa080075eb._comment
new file mode 100644
index 00000000..b24cebc6
--- /dev/null
+++ b/blog/entry/two_holiday_stories/comment_2_ca056666154a77fc55e325aa080075eb._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-12-12T21:10:21Z"
+ content="""
+I'm ok with either method for now, if it changes I'll let people know.
+"""]]

clarify
diff --git a/blog/entry/two_holiday_stories.mdwn b/blog/entry/two_holiday_stories.mdwn
index 836ae72e..639197ea 100644
--- a/blog/entry/two_holiday_stories.mdwn
+++ b/blog/entry/two_holiday_stories.mdwn
@@ -27,7 +27,7 @@ I have not used bitcoin for a long time. I could see a long time ago that
 its development community was unhealthy, that there was going to be a messy
 fork and I didn't want the drama of that. My bitcoin wallet files were long
 deleted. Checking my address online, I saw that in fact two people
-*had* reacted to Patreon by sending bitcoin to me.
+*had* reacted to Patreon by sending a little bit of bitcoin to me.
 
 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. 

Added a comment
diff --git a/blog/entry/two_holiday_stories/comment_1_d7f0afaa3e9e0259ec909e4a366b8264._comment b/blog/entry/two_holiday_stories/comment_1_d7f0afaa3e9e0259ec909e4a366b8264._comment
new file mode 100644
index 00000000..dd26d8a2
--- /dev/null
+++ b/blog/entry/two_holiday_stories/comment_1_d7f0afaa3e9e0259ec909e4a366b8264._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="lamby@8534e4c2b408c76c30ab7bf8979fdb14963b7ed5"
+ nickname="lamby"
+ avatar="http://cdn.libravatar.org/avatar/174735af8f1d16e861f90938241f403b"
+ subject="comment 1"
+ date="2017-12-12T09:21:50Z"
+ content="""
+I currently donate via Patreon. Would like me to move to LP?
+"""]]

link
diff --git a/blog/entry/two_holiday_stories.mdwn b/blog/entry/two_holiday_stories.mdwn
index d87cf9cf..836ae72e 100644
--- a/blog/entry/two_holiday_stories.mdwn
+++ b/blog/entry/two_holiday_stories.mdwn
@@ -4,9 +4,9 @@ for the holidays.
 ## Story the first: The Gift That Kept on Giving
 
 I have [a Patreon account](https://www.patreon.com/joeyh) that is a significant
-chunk of my funding to do what I do. Patreon has really pissed off a lot of
-people this week, and people are leaving it in droves. My Patreon funding
-is down 25%.
+chunk of my funding to do what I do. Patreon has really 
+[pissed off a lot of people this week](http://www.pretty-terrible.com/start-up-suicide-patreon-style/),
+and people are leaving it in droves. My Patreon funding is down 25%.
 
 This is an opportunity for Liberapay, which is run by a nonprofit, and
 avoids Patreon's excessive fees, and is free software to boot. So now

layout
diff --git a/blog/entry/two_holiday_stories.mdwn b/blog/entry/two_holiday_stories.mdwn
index 31ef3810..d87cf9cf 100644
--- a/blog/entry/two_holiday_stories.mdwn
+++ b/blog/entry/two_holiday_stories.mdwn
@@ -74,8 +74,10 @@ of my favorite answers.
 #### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 * I do! I wouldn't even have my job, if it wasn't for git-annex. ;-)
+
 * Yeah, it works great! If not for it I would not have noticed this data
   corruption until it was too late.
+
 * Indeed. All my stuff (around 3.5 terabytes) is stored in git-annex with 
   at least three copies of each file on different disks and locations, 
   spread over various hard disks, memory sticks, servers and you name it. 
@@ -85,68 +87,106 @@ of my favorite answers.
   In other words, Git-Annex and I are very happy together, and I'd like to 
   marry it. And because you are the father, I hereby respectfully ask for 
   your blessing.
+
 * Yes, git with git annex has revolutionised my scientific project file
   organisation and thats why I want to improve it.
+
 * <3 <3 <3
+
 * We use git-annex for our open-source FreeSurfer software and find very helpful
   indeed. Thank you. https://surfer.nmr.mgh.harvard.edu/
+
 * Yes I have! I've used it manage lots of video editing disks before, and
   am now migrating several slightly different copies of 15TB sized
   documentary footage from random USB3 disks and LTO tapes to a RAID server
   with BTRFS.
+
 * Oh yeah! This software is awesome. After getting used to having "dummy"
   shortcuts to content I don't currently have, with the simple ability to
   get/drop that content, I can't believe I haven't seen this anywhere before.
   If there is anything more impressive than this software, it's the support
   it has had from Joey over all this time. I'd have pulled my hair out long
   ago. :P
+
 * kinda
+
 * Yep, works apart from the few tests that fail.
+
 * Not yet, but I'm excited to make it work!
+
 * Roses are red  
   Violets are blue  
   git-annex is awesome  
   and so are you  
   `;-)`  
   But bloody hell, it's hard to get this thing to build.
+
 * git-annex is awesome, I lean on it heavily nearly every single day.
+
 * I have a couple of repositories atm, one with my music, another that backs up our family pictures for the family and uses Amazon S3 as a backup.
+
 * Yes! It's by far one of my favorite apps! it works very well on my laptop, on my home file server, and on my internal storage on my Android phone :)
+
 * Yes! I've been using git-annex quite a bit over the past year, for
   everything from my music collection to my personal files. Using it for a
   not-for-profit too. Even trying to get some Mac and Windows users to use
   it for our HOA's files.
+
 * I use git-annex for everything. I've got 10 repositories and around 2.5TB of data in those repos which in turn is synced all over the place. It's excellent.
+
 * Really nice tool.  Thanks Joey!
+
 * Git-annex rocks !!!!
+
 * I'd love to say I have. You'll hear my shout of joy when I do.
+
 * Mixed bag, works when it works, but I've had quite a few "unexplained" happenings. Perservering for now, hoping me reporting bugs will see things improve...
+
 * Yes !!! I'm moving all my files into my annex.  It is very robust; whenever something is wrong there is always some other copy somewhere that can be used.
+
 * Yes! git annex has been enormously helpful. Thanks so much for this tool.
+
 * Oh yes! I love git-annex :) I've written the hubiC special remote for git-annex, the zsh completion, contributed to the crowdfunding campaigns, and I'm a supporter on Patreon :)
+
 * Yes, managing 30000 files, on operating systems other than Windows though...
+
 * Of course ;) All the time
+
 * I trust Git Annex to keep hundreds of GB of data safe, and it has never failed me - despite my best efforts
+
 * Oh yeah, I am still discovering this powerfull git annex tool. 
   In fact, collegues and I are forming a group during the process to exchange about different use cases, encountered problems and help each other.
+
 * I love the metadata functionality so much that I wrote a gui for metadata operations and discovered this bug.
+
 * Sure, it works marvels :-) Also what I was trying to do is perhaps not by the book...
+
 * Oh, yes. It rules. :) One of the most important programs I use because I have all my valuable stuff in it. My files have never been safer.
+
 * I'm an extremely regular user of git-annex on OS X and Linux, for several
   years, using it as a podcatcher and to manage most of my "large file"
   media.  It's one of those "couldn't live without" tools.  Thanks for
   writing it.
+
 * Yes, I've been using git annex for I think a year and a half now, on
   several repositories. It works pretty well. I have a total of around 315GB
   and 23K annexed keys across them (counting each annex only once, even
   though they're cloned on a bunch of machines).
+
 * I only find (what I think are) bugs because I use it and I use it because I like it. I like it because it works (except for when I find actual bugs :]).
+
 * I'm new to git-annex and immediately astonished by its unique strength.
+
 * As mentioned before, I am very, very happy with git-annex :-) Discovery of 2015 for me.
+
 * git-annex is great and revolutionized my file organization and backup structure (if they were even existing before)
+
 * That’s just a little hiccup in, up to now, various months of merry use! ;-)
+
 * Yes.  Love it.  Donated.  Have been using it for years.  Recommend it and get(/force) my collaborators to use it.  ;-)
+
 * git-annex is an essential building block in my digital life style!
+
 * Well, git-annex is wonderful!
 
 A lil' positive end note turned into a big one, eh? :)

header size
diff --git a/blog/entry/two_holiday_stories.mdwn b/blog/entry/two_holiday_stories.mdwn
index 1d11f2e6..31ef3810 100644
--- a/blog/entry/two_holiday_stories.mdwn
+++ b/blog/entry/two_holiday_stories.mdwn
@@ -53,7 +53,7 @@ I do hope that [Liberapay](https://liberapay.com/joeyh/) works out.
 I added this to the end of git-annex's bug report template on a whim
 two years ago:
 
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+#### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 That prompt turned out to be much more successful than I had expected, and
 so I want to pass the gift of the idea on to you. Consider adding
@@ -71,7 +71,7 @@ git-annex users, including the git-annex user surveys. Out of 217 bug
 reports that used this template, 182 answered the question. Here are some
 of my favorite answers.
 
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+#### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 * I do! I wouldn't even have my job, if it wasn't for git-annex. ;-)
 * Yeah, it works great! If not for it I would not have noticed this data

header size
diff --git a/blog/entry/two_holiday_stories.mdwn b/blog/entry/two_holiday_stories.mdwn
index 3a1cee02..1d11f2e6 100644
--- a/blog/entry/two_holiday_stories.mdwn
+++ b/blog/entry/two_holiday_stories.mdwn
@@ -1,7 +1,7 @@
 Two stories of something nice coming out of something not-so-nice
 for the holidays.
 
-# Story the first: The Gift That Kept on Giving
+## Story the first: The Gift That Kept on Giving
 
 I have [a Patreon account](https://www.patreon.com/joeyh) that is a significant
 chunk of my funding to do what I do. Patreon has really pissed off a lot of
@@ -48,7 +48,7 @@ that I've sold it. And so I will be having a happy holidays, no matter how
 the Patreon implosion goes. But for sustainable funding going forward, 
 I do hope that [Liberapay](https://liberapay.com/joeyh/) works out.
 
-# Story the second: "a lil' positive end note does wonders"
+## Story the second: "a lil' positive end note does wonders"
 
 I added this to the end of git-annex's bug report template on a whim
 two years ago:

blog update
diff --git a/blog/entry/two_holiday_stories.mdwn b/blog/entry/two_holiday_stories.mdwn
new file mode 100644
index 00000000..3a1cee02
--- /dev/null
+++ b/blog/entry/two_holiday_stories.mdwn
@@ -0,0 +1,152 @@
+Two stories of something nice coming out of something not-so-nice
+for the holidays.
+
+# Story the first: The Gift That Kept on Giving
+
+I have [a Patreon account](https://www.patreon.com/joeyh) that is a significant
+chunk of my funding to do what I do. Patreon has really pissed off a lot of
+people this week, and people are leaving it in droves. My Patreon funding
+is down 25%.
+
+This is an opportunity for Liberapay, which is run by a nonprofit, and
+avoids Patreon's excessive fees, and is free software to boot. So now
+I have a [Liberapay account](https://liberapay.com/joeyh/) and have
+diversified my sustainable funding some more, although only half of
+the people I lost from Patreon have moved over. A few others have found other
+ways to donate to me, including snail mail and Paypal, and others
+I'll just lose. Thanks, Patreon..
+
+Yesterday I realized I should check if anyone had decided to send me
+Bitcoin. Bitcoin donations are weird because noone ever tells me that
+they made them. Also because it's never clear if the motive is to get me
+invested in bitcoin or send me some money. I prefer not to be invested in
+risky currency speculation, preferring risks like "write free software
+without any clear way to get paid for it", so I always cash it out immediately.
+
+I have not used bitcoin for a long time. I could see a long time ago that
+its development community was unhealthy, that there was going to be a messy
+fork and I didn't want the drama of that. My bitcoin wallet files were long
+deleted. Checking my address online, I saw that in fact two people
+*had* reacted to Patreon by sending bitcoin to me.
+
+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.
+
+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
+about "some long forgotten bitcoin wallet" -- you know where this is going
+right?
+
+Yeah, well it didn't have a life changing amount of bitcoin in it, but it
+had a little almost-dust from a long-ago bitcoin donor, which at current
+crazy bitcoin prices, is enough that I may need to fill out a tax form now
+that I've sold it. And so I will be having a happy holidays, no matter how
+the Patreon implosion goes. But for sustainable funding going forward, 
+I do hope that [Liberapay](https://liberapay.com/joeyh/) works out.
+
+# Story the second: "a lil' positive end note does wonders"
+
+I added this to the end of git-annex's bug report template on a whim
+two years ago:
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+That prompt turned out to be much more successful than I had expected, and
+so I want to pass the gift of the idea on to you. Consider adding
+something like that to your project's bug report template.
+
+It really works: I'll see a bug report be lost and confused and
+discouraged, and keep reading to make sure I see whatever nice thing there
+might be at the end. It's not just about meaningless politeness either,
+it's about getting an impression about whether the user is having any
+success at all, and how experienced they are in general, which is important
+in understanding where a bug report is coming from.
+
+I've learned more from it than I have from most other interactions with
+git-annex users, including the git-annex user surveys. Out of 217 bug
+reports that used this template, 182 answered the question. Here are some
+of my favorite answers.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+* I do! I wouldn't even have my job, if it wasn't for git-annex. ;-)
+* Yeah, it works great! If not for it I would not have noticed this data
+  corruption until it was too late.
+* Indeed. All my stuff (around 3.5 terabytes) is stored in git-annex with 
+  at least three copies of each file on different disks and locations, 
+  spread over various hard disks, memory sticks, servers and you name it. 
+  Unused disk space is a waste, so I fill everything up to the brim with 
+  extra copies.
+
+  In other words, Git-Annex and I are very happy together, and I'd like to 
+  marry it. And because you are the father, I hereby respectfully ask for 
+  your blessing.
+* Yes, git with git annex has revolutionised my scientific project file
+  organisation and thats why I want to improve it.
+* <3 <3 <3
+* We use git-annex for our open-source FreeSurfer software and find very helpful
+  indeed. Thank you. https://surfer.nmr.mgh.harvard.edu/
+* Yes I have! I've used it manage lots of video editing disks before, and
+  am now migrating several slightly different copies of 15TB sized
+  documentary footage from random USB3 disks and LTO tapes to a RAID server
+  with BTRFS.
+* Oh yeah! This software is awesome. After getting used to having "dummy"
+  shortcuts to content I don't currently have, with the simple ability to
+  get/drop that content, I can't believe I haven't seen this anywhere before.
+  If there is anything more impressive than this software, it's the support
+  it has had from Joey over all this time. I'd have pulled my hair out long
+  ago. :P
+* kinda
+* Yep, works apart from the few tests that fail.
+* Not yet, but I'm excited to make it work!
+* Roses are red  
+  Violets are blue  
+  git-annex is awesome  
+  and so are you  
+  `;-)`  
+  But bloody hell, it's hard to get this thing to build.
+* git-annex is awesome, I lean on it heavily nearly every single day.
+* I have a couple of repositories atm, one with my music, another that backs up our family pictures for the family and uses Amazon S3 as a backup.
+* Yes! It's by far one of my favorite apps! it works very well on my laptop, on my home file server, and on my internal storage on my Android phone :)
+* Yes! I've been using git-annex quite a bit over the past year, for
+  everything from my music collection to my personal files. Using it for a
+  not-for-profit too. Even trying to get some Mac and Windows users to use
+  it for our HOA's files.
+* I use git-annex for everything. I've got 10 repositories and around 2.5TB of data in those repos which in turn is synced all over the place. It's excellent.
+* Really nice tool.  Thanks Joey!
+* Git-annex rocks !!!!
+* I'd love to say I have. You'll hear my shout of joy when I do.
+* Mixed bag, works when it works, but I've had quite a few "unexplained" happenings. Perservering for now, hoping me reporting bugs will see things improve...
+* Yes !!! I'm moving all my files into my annex.  It is very robust; whenever something is wrong there is always some other copy somewhere that can be used.
+* Yes! git annex has been enormously helpful. Thanks so much for this tool.
+* Oh yes! I love git-annex :) I've written the hubiC special remote for git-annex, the zsh completion, contributed to the crowdfunding campaigns, and I'm a supporter on Patreon :)
+* Yes, managing 30000 files, on operating systems other than Windows though...
+* Of course ;) All the time
+* I trust Git Annex to keep hundreds of GB of data safe, and it has never failed me - despite my best efforts
+* Oh yeah, I am still discovering this powerfull git annex tool. 
+  In fact, collegues and I are forming a group during the process to exchange about different use cases, encountered problems and help each other.
+* I love the metadata functionality so much that I wrote a gui for metadata operations and discovered this bug.
+* Sure, it works marvels :-) Also what I was trying to do is perhaps not by the book...
+* Oh, yes. It rules. :) One of the most important programs I use because I have all my valuable stuff in it. My files have never been safer.
+* I'm an extremely regular user of git-annex on OS X and Linux, for several
+  years, using it as a podcatcher and to manage most of my "large file"
+  media.  It's one of those "couldn't live without" tools.  Thanks for
+  writing it.
+* Yes, I've been using git annex for I think a year and a half now, on
+  several repositories. It works pretty well. I have a total of around 315GB
+  and 23K annexed keys across them (counting each annex only once, even
+  though they're cloned on a bunch of machines).
+* I only find (what I think are) bugs because I use it and I use it because I like it. I like it because it works (except for when I find actual bugs :]).
+* I'm new to git-annex and immediately astonished by its unique strength.
+* As mentioned before, I am very, very happy with git-annex :-) Discovery of 2015 for me.
+* git-annex is great and revolutionized my file organization and backup structure (if they were even existing before)
+* That’s just a little hiccup in, up to now, various months of merry use! ;-)
+* Yes.  Love it.  Donated.  Have been using it for years.  Recommend it and get(/force) my collaborators to use it.  ;-)
+* git-annex is an essential building block in my digital life style!
+* Well, git-annex is wonderful!
+
+A lil' positive end note turned into a big one, eh? :)

Added a comment: HOWTO OLE object collision?
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_9_a095f353f8ecc71856b871a8757ab182._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_9_a095f353f8ecc71856b871a8757ab182._comment
new file mode 100644
index 00000000..ed60ad45
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_9_a095f353f8ecc71856b871a8757ab182._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Oto"
+ subject="HOWTO OLE object collision?"
+ date="2017-12-11T10:42:49Z"
+ content="""
+Is it possible to make the both colliding PDFs as OLE objects with same hash? 
+For example so when OLE object is embedded in any file then both objects can be interchanged without changing file hash?
+"""]]

add liberapay
diff --git a/thanks.mdwn b/thanks.mdwn
index c25d5e64..c27092cd 100644
--- a/thanks.mdwn
+++ b/thanks.mdwn
@@ -3,6 +3,6 @@ I do, a note is always the best way to make me happy, but here are some
 more tangible options:
 
 * paypal joey@kitenet.net
-* [support me on Patreon](https://patreon.com/joeyh)
+* [support me on Patreon](https://patreon.com/joeyh) or [Liberapay](https://liberapay.com/joeyh/)
 * [My Amazon wishlist](http://www.amazon.com/gp/registry/registry.html/104-5960215-8415137?ie=UTF8&type=wishlist&id=H9MGKNPCYVS2)
 * bitcoin address: <a href="bitcoin:[[!inline raw=yes pages=bitcoin]]">[[!inline raw=yes pages=bitcoin]]</a>

add
diff --git a/pics/snapshots/circle-liberapay.jpg b/pics/snapshots/circle-liberapay.jpg
new file mode 100644
index 00000000..dc7a2a92
Binary files /dev/null and b/pics/snapshots/circle-liberapay.jpg differ

add
diff --git a/pics/snapshots/circle.jpg b/pics/snapshots/circle.jpg
new file mode 100644
index 00000000..b966decf
Binary files /dev/null and b/pics/snapshots/circle.jpg differ

Added a comment: long route examples
diff --git a/blog/entry/stupid_long_route/comment_1_26aefa85ffb45598ef6d87dd5cea7baa._comment b/blog/entry/stupid_long_route/comment_1_26aefa85ffb45598ef6d87dd5cea7baa._comment
new file mode 100644
index 00000000..5f86b761
--- /dev/null
+++ b/blog/entry/stupid_long_route/comment_1_26aefa85ffb45598ef6d87dd5cea7baa._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="don@db7bb73c86870ebaa36db90655ebdcc4592a05bc"
+ nickname="don"
+ avatar="http://cdn.libravatar.org/avatar/85ec91e6afbae5704a038e93ef4eb019"
+ subject="long route examples"
+ date="2017-12-07T03:13:59Z"
+ content="""
+I think many people working on computers back then have such stories.  My personal one involved a Pyramid Unix machine, connected on CSNET, next to an IBM 4381 mainframe, on BITNET, in the Office of Computer Services building at Georgia Tech.  Transferring files electronically required using the CSNET/Arpa/BITNET relays, the latter which was either in Minnesota or New York.  I can also think of examples even in the early 1980s when the easiest method to get files on modem-accessible machines was to find an old teletype and punch paper tape and then replay it on the second machine.  What an improvement Kermit later was!
+
+
+"""]]

blog
diff --git a/blog/entry/new_old_thing.mdwn b/blog/entry/new_old_thing.mdwn
new file mode 100644
index 00000000..1a6f8be8
--- /dev/null
+++ b/blog/entry/new_old_thing.mdwn
@@ -0,0 +1,16 @@
+[[!img blog/pics/woodclose.jpg alt="closeup of red knothole, purple-pink and
+yellow wood grain"]]
+
+This branch came from a cedar tree overhanging my driveway.
+
+It was fun to bust this open and shape it with hammer and chisels. My dad
+once recommended learning to chisel before learning any power tools for
+wood working.. so I suppose this is a start.
+
+[[!img blog/pics/wooddistant.jpg alt="roughly split wood branch"]]
+
+Some tung oil and drilling later, and I'm very pleased to have a nice place
+to hang my cast iron.
+
+[[!img blog/pics/rack.jpg alt="slightly curved wood beam with cast iron
+pots hung from it"]]
diff --git a/blog/pics/rack.jpg b/blog/pics/rack.jpg
index e7b6491e..927ee669 100644
Binary files a/blog/pics/rack.jpg and b/blog/pics/rack.jpg differ
diff --git a/blog/pics/woodclose.jpg b/blog/pics/woodclose.jpg
new file mode 100644
index 00000000..fc38c37c
Binary files /dev/null and b/blog/pics/woodclose.jpg differ
diff --git a/blog/pics/wooddistant.jpg b/blog/pics/wooddistant.jpg
new file mode 100644
index 00000000..c28d4eb1
Binary files /dev/null and b/blog/pics/wooddistant.jpg differ

thought
diff --git a/code/scroll/thoughts.mdwn b/code/scroll/thoughts.mdwn
index 8ce15998..74d71ec6 100644
--- a/code/scroll/thoughts.mdwn
+++ b/code/scroll/thoughts.mdwn
@@ -52,6 +52,13 @@ A few random bits about the game design etc.
   similar to how hunger works in other roguelikes, but more visual, and
   that the final "scroll rolls up" endgame fell out for nearly free.
 
+* I've always been fascinated by the prohibition in the GPL against
+  changing it. The free software license is not licensed freely.
+  However, I didn't notice that the game often involves changing
+  the text of the GPL until recently. Whether this means the game violates
+  the license of its own license is left as an exercise for the reader's
+  lawyers.
+
 * The level generation, such as it is, was a series of happy accidents.
   All I was sure about was the GPL would be in the mix. Given how classic
   the source material used is, I wanted to keep close to it, rather than

stack
less likely to bit rot than cabal
diff --git a/code/scroll.mdwn b/code/scroll.mdwn
index 5ae54496..c70eddc3 100644
--- a/code/scroll.mdwn
+++ b/code/scroll.mdwn
@@ -17,17 +17,18 @@ For a quick play on the web, there are two demo servers up!
 * EU <http://eu.scroll.joeyh.name:4242/>
 * US <http://us.scroll.joeyh.name:4242/>
 
-## install `scroll`
+## build `scroll` from source
 
 [Git repository](https://git.joeyh.name/index.cgi/scroll.git/)
 
 Requires ncurses, on Linux or Similar.
 
-To build, first install the [Haskell Platform](http://www.haskell.org/platform/),
-and then run:
+To build, first install the [Haskell Stack](https://docs.haskellstack.org/en/stahttps://docs.haskellstack.org/en/stable/README/ble/README/#how-to-install),
+and then clone the git repository and inside it, run:
 
-	cabal update
-	cabal install scroll --bindir=$HOME/bin
+	stack exec scroll
+
+You can also use `stack install` to install it.
 
 Scroll is also available in [NixOS](http://hydra.nixos.org/job/nixpkgs/haskell-updates/haskellngPackages.scroll.x86_64-linux)!
 

fix git repo links for cgit
diff --git a/blog/entry/announcing_olduse.net.mdwn b/blog/entry/announcing_olduse.net.mdwn
index 9d017b21..9971f439 100644
--- a/blog/entry/announcing_olduse.net.mdwn
+++ b/blog/entry/announcing_olduse.net.mdwn
@@ -51,7 +51,7 @@ Usenet's flowering.
   12 hours. When I realized I also needed an A-News to B-News converter,
   I knew it was worth it to have done things right, because that took
   only 43 more lines, and worked 100% on the first run!
-  My code repository for olduse.net is [here](http://git.joeyh.name/?p=oldusenet.git;a=summary).
+  My code repository for olduse.net is [here](https://git.joeyh.name/index.cgi/oldusenet.git/).
 
 ----
 
diff --git a/blog/entry/introducing_propellor.mdwn b/blog/entry/introducing_propellor.mdwn
index e8d21a16..ebaa3bb6 100644
--- a/blog/entry/introducing_propellor.mdwn
+++ b/blog/entry/introducing_propellor.mdwn
@@ -15,7 +15,7 @@ debconf, which claims to be the "Debian Configuration Management system"..
 But I didn't understand configuration management back then either.)
 
 So, propellor makes some perhaps wacky choices. The least of these
-is that it's built from [a git repository](http://git.joeyh.name/?p=propellor.git;a=summary)
+is that it's built from [a git repository](https://git.joeyh.name/index.cgi/propellor.git/)
 that any (theoretical) other users will fork and modify; a cron job can
 re-make it from time to time and pull down configuration changes, or
 *something* can be run to push changes.
diff --git a/code/scriptreplay.mdwn b/code/scriptreplay.mdwn
index 874b37ea..fbea34ee 100644
--- a/code/scriptreplay.mdwn
+++ b/code/scriptreplay.mdwn
@@ -28,4 +28,4 @@ and have made a number of improvements to it, some of which have been
 included in the Debian package, but none of which seem to have gotten back
 to upstream as of yet. A number of my other patches to ttyrec, including
 using inotify to improve live playback of ttyrecord, are languishing 
-in a [git repository](https://git.joeyh.name/?p=zzattic/ttyrec.git;a=summary).
+in a [git repository](https://git.joeyh.name/index.cgi/zzattic/ttyrec.git/).
diff --git a/code/scroll.mdwn b/code/scroll.mdwn
index 49cdcab3..5ae54496 100644
--- a/code/scroll.mdwn
+++ b/code/scroll.mdwn
@@ -19,7 +19,7 @@ For a quick play on the web, there are two demo servers up!
 
 ## install `scroll`
 
-[Git repository](http://git.joeyh.name/?p=scroll.git;a=summary)
+[Git repository](https://git.joeyh.name/index.cgi/scroll.git/)
 
 Requires ncurses, on Linux or Similar.
 

blog update
diff --git a/blog/entry/Happy_Thanksgiving.mdwn b/blog/entry/Happy_Thanksgiving.mdwn
new file mode 100644
index 00000000..110983f9
--- /dev/null
+++ b/blog/entry/Happy_Thanksgiving.mdwn
@@ -0,0 +1,7 @@
+[[!img pics/groupphoto.png]]
+
+After thanksgiving at my sister's, I got the fun of a big family visit
+without the turkey day stress. We ate lemons and stuffed three people
+inside a tree.
+
+[[!img pics/kidtree.jpg]]
diff --git a/blog/pics/kidtree.jpg b/blog/pics/kidtree.jpg
new file mode 100644
index 00000000..840d0363
Binary files /dev/null and b/blog/pics/kidtree.jpg differ

added
diff --git a/blog/pics/groupphoto.png b/blog/pics/groupphoto.png
new file mode 100644
index 00000000..b46f0e0e
Binary files /dev/null and b/blog/pics/groupphoto.png differ

typo
diff --git a/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn b/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn
index 0bfe1ba1..ca3a9119 100644
--- a/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn
+++ b/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn
@@ -11,7 +11,7 @@ and a root password:
 	lime = host "lime.example.com" $ props
 		& osDebian Unstable ARMHF
 		& Machine.olimex_A10_OLinuXino_LIME
-		& hasPartiton (partition EXT4 `mountedAt` "/" `setSize` MegaBytes 8192)
+		& hasPartition (partition EXT4 `mountedAt` "/" `setSize` MegaBytes 8192)
 	        & hasPassword (User "root")
 	        & Ssh.installed
 		& Ssh.permitRootLogin (RootLogin True)

indentation
diff --git a/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn b/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn
index 9bf7c794..0bfe1ba1 100644
--- a/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn
+++ b/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn
@@ -45,7 +45,7 @@ about the Olimex LIME:
 
 	olimex_A10_OLinuXino_LIME :: Property (HasInfo + DebianLike)
 	olimex_A10_OLinuXino_LIME = FlashKernel.installed "Olimex A10-OLinuXino-LIME"
-	        `requires` sunixi "A10-OLinuXino-Lime"
+		`requires` sunixi "A10-OLinuXino-Lime"
 		`requires` armmp
 
 My home server is a CubieTruck which serves as a wireless access point,

blog
diff --git a/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn b/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn
new file mode 100644
index 00000000..9bf7c794
--- /dev/null
+++ b/blog/entry/custom_ARM_disk_image_generation_with_propellor.mdwn
@@ -0,0 +1,57 @@
+Following up on [[blog/entry/propelling_disk_images]], 
+[[code/Propellor]] can now build custom ARM disk images for a variety of
+different ARM boards. The disk image build can run on a powerful laptop or
+server, so it's super fast and easy compared with manually installing
+Debian on an ARM board.
+
+Here's a simple propellor config for a Olimex LIME board, with ssh access
+and a root password:
+
+	lime :: Host
+	lime = host "lime.example.com" $ props
+		& osDebian Unstable ARMHF
+		& Machine.olimex_A10_OLinuXino_LIME
+		& hasPartiton (partition EXT4 `mountedAt` "/" `setSize` MegaBytes 8192)
+	        & hasPassword (User "root")
+	        & Ssh.installed
+		& Ssh.permitRootLogin (RootLogin True)
+
+To make a disk image for that board, I only have to add this property to my
+laptop:
+
+	& imageBuiltFor lime
+		(RawDiskImage "/srv/lime.img")
+		(Debootstrapped mempty)
+
+Propellor knows what kernel to install and how to make the image bootable
+for a [bunch of ARM boards](http://hackage.haskell.org/package/propellor/docs/Propellor-Property-Machine.html),
+including the Olimex LIME, the SheevaPlug, Banana Pi, and CubieTruck.
+
+To build the disk image targeting ARM, propellor uses qemu. So it's helpful
+that, after the first build, propellor incrementally updates disk images,
+quite quickly and efficiently.
+
+Once the board has the image installed, you can run propellor on it to
+further maintain it, and if there's a hardware problem, you can quickly
+replace it with an updated image.
+
+[[!img pics/armtower.jpg caption="computer tower that I will be
+maintaining with propellor"]]
+
+It's fairly simple to teach propellor about other ARM boards, so it
+should be quite easy to keep propellor knowing about all ARM boards
+supported by Debian (and other distros). Here's how I taught it
+about the Olimex LIME:
+
+	olimex_A10_OLinuXino_LIME :: Property (HasInfo + DebianLike)
+	olimex_A10_OLinuXino_LIME = FlashKernel.installed "Olimex A10-OLinuXino-LIME"
+	        `requires` sunixi "A10-OLinuXino-Lime"
+		`requires` armmp
+
+My home server is a CubieTruck which serves as a wireless access point,
+solar panel data collector, and git-annex autobuilder. It's deployed from
+a disk image built by propellor,
+[using this config](https://git.joeyh.name/index.cgi/propellor.git/tree/joeyconfig.hs?h=joeyconfig&id=002d86bdcd88dcf03941e0b40f4f175c1fd3cba6#n179).
+I've been involved with building disk image for ARM boards for a long
+time -- it was part of my job for five years -- and this is the first time
+I've been entirely happy with the process.

previously
diff --git a/blog/entry/stupid_long_route.mdwn b/blog/entry/stupid_long_route.mdwn
index 706402b1..414a3cd6 100644
--- a/blog/entry/stupid_long_route.mdwn
+++ b/blog/entry/stupid_long_route.mdwn
@@ -46,3 +46,5 @@ key:
 
 Not bad for a lazy solution to a problem that could have been solved by
 walking across the room, eh?
+
+Previously: [[roundtrip_latency_from_a_cabin_with_dialup_in_2011]]

remove identica feed
diff --git a/blog.mdwn b/blog.mdwn
index 41ef4d0c..d0e52367 100644
--- a/blog.mdwn
+++ b/blog.mdwn
@@ -34,8 +34,4 @@ Other feeds:
 * [[lay]]
 * [[grep]]
 * more listed in [[about]]
-
-Recent [chatter](https://identi.ca/joeyh):
-[[!inline pages="internal(grep/identi.ca_posts/*)" template="microblog" show=5 feeds=no]]
-
 """]]

layout
diff --git a/blog/entry/stupid_long_route.mdwn b/blog/entry/stupid_long_route.mdwn
index 3afa0ab8..706402b1 100644
--- a/blog/entry/stupid_long_route.mdwn
+++ b/blog/entry/stupid_long_route.mdwn
@@ -28,14 +28,16 @@ So, I sshed to a computer in New Jersey. And from there I sshed to my
 access point. And the latency was amazing. Because, every time I pressed a
 key:
 
-* It was sent to a satellite in geosynchrous orbit, 22250 miles high.
+* It was sent to a satellite in geosynchrous orbit, 22250 miles high.  
   [[!img blog/pics/viasat.jpg]]
 * Which beamed it back to a ground station in Texas, another 22250 miles.
 * Which routed it over cable to New Jersey to my server there.
 * Which bounced it back to a Texas-size dish, which zapped it back to orbit,
-  another 22250 miles. [[!img blog/pics/bigdish.jpg]]
+  another 22250 miles.  
+  [[!img blog/pics/bigdish.jpg]]
 * And the satellite transmitted it back in the general direction of my house,
-  another 22250 miles. [[!img blog/pics/viasatbeam.png]]
+  another 22250 miles.  
+  [[!img blog/pics/viasatbeam.png]]
 * So my keystroke finally reached the access point. But then it had to show
   me it had received it. So that whole process happened again in reverse,
   adding another 89000 miles travel total.

retitle
diff --git a/blog/entry/stupid_routing.mdwn b/blog/entry/stupid_long_route.mdwn
similarity index 100%
rename from blog/entry/stupid_routing.mdwn
rename to blog/entry/stupid_long_route.mdwn

blog update
diff --git a/blog/entry/stupid_routing.mdwn b/blog/entry/stupid_routing.mdwn
new file mode 100644
index 00000000..3afa0ab8
--- /dev/null
+++ b/blog/entry/stupid_routing.mdwn
@@ -0,0 +1,46 @@
+There's an old net story from the 80's, which I can't find right now, but
+is about two computers, 10 feet apart, having a ridiculously long network
+route between them, packets traveling into other states or countries and
+back, when they could have flowed over a short cable.
+
+Ever since I read that, I've been collecting my own ridiculously long
+routes. ssh bouncing from country to country, making letters I type travel
+all the way around the world until they echo back on my screen. Tasting the
+latency that's one of the only ways we can viscerally understand just how
+big a tangle of wires humanity has built.
+
+Yesterday, I surpassed all that, and I did it in a way that hearkens right
+back to the original story. I had two computers, 20 feet apart, I wanted
+one to talk to the other, and the route between the two ended up traveling
+not around the Earth, but almost the distance to the Moon.
+
+I was rebuilding my home's access point, and ran into a
+[annoying bug](http://bugs.debian.org/882050) that prevented it from
+listening to wifi. I knew it was still connected over ethernet to the
+satellite receiver.
+
+I connected my laptop to the satellite receiver over wifi. But, I didn't
+know the IP address to reach the access point. Then I remembered 
+I had set it up so incoming ssh to the satellite receiver was directed
+to the access point.
+
+So, I sshed to a computer in New Jersey. And from there I sshed to my
+access point. And the latency was amazing. Because, every time I pressed a
+key:
+
+* It was sent to a satellite in geosynchrous orbit, 22250 miles high.
+  [[!img blog/pics/viasat.jpg]]
+* Which beamed it back to a ground station in Texas, another 22250 miles.
+* Which routed it over cable to New Jersey to my server there.
+* Which bounced it back to a Texas-size dish, which zapped it back to orbit,
+  another 22250 miles. [[!img blog/pics/bigdish.jpg]]
+* And the satellite transmitted it back in the general direction of my house,
+  another 22250 miles. [[!img blog/pics/viasatbeam.png]]
+* So my keystroke finally reached the access point. But then it had to show
+  me it had received it. So that whole process happened again in reverse,
+  adding another 89000 miles travel total.
+* And finally, after 178000 and change miles of data transfer, the letter
+  I'd typed a full second ago appeared on my screen.
+
+Not bad for a lazy solution to a problem that could have been solved by
+walking across the room, eh?
diff --git a/blog/pics/bigdish.jpg b/blog/pics/bigdish.jpg
new file mode 100644
index 00000000..98ca8402
Binary files /dev/null and b/blog/pics/bigdish.jpg differ
diff --git a/blog/pics/viasat.jpg b/blog/pics/viasat.jpg
new file mode 100644
index 00000000..e59a19f7
Binary files /dev/null and b/blog/pics/viasat.jpg differ
diff --git a/blog/pics/viasatbeam.png b/blog/pics/viasatbeam.png
new file mode 100644
index 00000000..9e8e1846
Binary files /dev/null and b/blog/pics/viasatbeam.png differ

devblog
diff --git a/blog/pics/armtower.jpg b/blog/pics/armtower.jpg
new file mode 100644
index 00000000..78d7392a
Binary files /dev/null and b/blog/pics/armtower.jpg differ
diff --git a/devblog/propellor_arm_boards_testing.mdwn b/devblog/propellor_arm_boards_testing.mdwn
new file mode 100644
index 00000000..06b8228e
--- /dev/null
+++ b/devblog/propellor_arm_boards_testing.mdwn
@@ -0,0 +1,21 @@
+Took a while to find the necessary serial cables and SD cards to test
+propellor's ARM disk image generation capabilies. 
+
+Ended up adding support for the SheevaPlug because it was the first board I
+found the hardware to test. And after fixing a couple oversights, it worked
+on the second boot!
+
+Then after a trip to buy a microSD card, 
+Olimex Lime worked on the *first* boot! So did CubieTruck and Banana Pi.
+I went ahead and added a dozen other sunxi boards that Debian supports,
+which will probably all work.
+
+(Unfortunately I accidentially corrupted the disk of my home server
+(router/solar power monitor/git-annex build box) while testing the
+CubieTruck. Luckily, that server was the first ARM board I want to rebuild
+cleanly with propellor, and its configuration was almost entirely in
+propellor already, so rebuilding it now.)
+
+----
+
+Today's work was sponsored by Trenton Cronholm on Patreon.

devblog
diff --git a/devblog/propellor_arm_boards.mdwn b/devblog/propellor_arm_boards.mdwn
new file mode 100644
index 00000000..cca4ec3d
--- /dev/null
+++ b/devblog/propellor_arm_boards.mdwn
@@ -0,0 +1,27 @@
+Working today on adding support for ARM boards to propellor.
+
+I started by adding support for generating non-native chroots.
+`qemu-debootstrap` makes that fairly simple. Propellor is able to run
+inside a non-native chroot too, to ensure properties in there;
+the way it injects itself into a chroot wins again as that just worked.
+
+Then, added support for flash-kernel, and for u-boot installation.
+Installing u-boot to the boot sector of SD cards used by common ARM boards
+does not seem to be automated anywhere in Debian, just README.Debian files
+document `dd` commands. It may be that's not needed for a lot of boards
+(my CubieTruck boots without it), but I implemented it anyway.
+
+And, Propellor.Property.Machine is a new module with properties for
+different ARM boards, to get the right kernel/flash-kernel/u-boot/etc
+configuration easily.
+
+This all works, and propellor can update a bootable disk image for an ARM
+system in 30 seconds. I have not checked yet if it's really bootable.
+
+Tomorrow, I'm going to dust off my ARM boards and try to get at least 3
+boards tested, and if that goes well, will probably add untested properties
+for all the rest of the sunxi boards.
+
+---
+
+Today's work was sponsored by Jake Vosloo on Patreon.

poll vote (not interested)
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 393d2163..44c6141b 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" 12 "not interested"]]
+[[!poll 47 "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]]

Fix a link and correct some spelling mistakes
diff --git a/blog/entry/moving_my_email_archives_and_packages_to_git-annex.mdwn b/blog/entry/moving_my_email_archives_and_packages_to_git-annex.mdwn
index 19aea341..8889c979 100644
--- a/blog/entry/moving_my_email_archives_and_packages_to_git-annex.mdwn
+++ b/blog/entry/moving_my_email_archives_and_packages_to_git-annex.mdwn
@@ -1,5 +1,5 @@
 I've recently been moving some important data into [[code/git-annex]],
-and finding it simplifies things while also increasing my flexability.
+and finding it simplifies things while also increasing my flexibility.
 
 ## email archives
 
@@ -25,21 +25,21 @@ maildir folder. Then `mailfilter` sorts it into the folders I sync (with
 `offlineimap`) and read. Each day, the "raw" folder is moved into a mbox
 archive, and that's added to the git annex. Each month, the mail I've read is
 moved into a monthly archives, and added to the git annex.
-A [simple script](http://git.joeyh.name/?p=joey/home.git;a=blob;f=bin/trimail)
+A [simple script](https://git.joeyh.name/index.cgi/joey/home.git/tree/bin/trimail)
 does the work.
 
 I counted the number of copies that existed of my mail when it was stored in
-git, and found 7 copies spread amoung just 3 drives. I decided to slim that
+git, and found 7 copies spread among just 3 drives. I decided to slim that
 back, and configured git-annex to require only 5 copies. But those 5 copies
-will spread amoung more drives, including several offline archival drives, so
+will spread among more drives, including several offline archival drives, so
 it will be more robust overall.
 
 My netbook will have an incomplete checkout of my mail, omitting the "raw"
 archive. If I need to peek inside a spam folder for a lost mail, I can
 quickly pull it down; if I need to free up space I can quickly drop
-older archives. This is the flexability that git-annex fans love. :)
+older archives. This is the flexibility that git-annex fans love. :)
 
-By the way, this also makes it easier to permanantly delete mail, when you
+By the way, this also makes it easier to permanently delete mail, when you
 really need to (ie, for contractual reasons). Before, I'd have to do a
 painful `git-filter-branch` if I needed to get rid of eg, mail for old
 jobs. Now I can `git annex drop --force`.
@@ -52,7 +52,7 @@ verifying checksums as it goes:
 
 	cd ~/mail/archive; find -type l -exec git annex reinject ~/mail.old/archive/{} {} \;
 
-Note on mairix compatability: I use mairix to index and search my mail.
+Note on mairix compatibility: I use mairix to index and search my mail.
 But it refuses to follow git-annex's symlinks to the content. So I have
 to point it at `.git/annex/objects/`. I also configured annex.backend to
 SHA256E, which keeps the extensions on my compressed mailbox files, which

removed
diff --git a/blog/entry/extending_Scuttlebutt_with_Annah/comment_1_2f961925857d162d639186c22960e0b7._comment b/blog/entry/extending_Scuttlebutt_with_Annah/comment_1_2f961925857d162d639186c22960e0b7._comment
deleted file mode 100644
index 57c04e4a..00000000
--- a/blog/entry/extending_Scuttlebutt_with_Annah/comment_1_2f961925857d162d639186c22960e0b7._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="philipp+joey@d05249cd745f3c0d62b466cee3903237e9fb8c5f"
- nickname="philipp+joey"
- avatar="http://cdn.libravatar.org/avatar/24a924aa7c29ee08d1e8acea81b1efc8"
- subject="Broken Link"
- date="2017-10-18T22:23:17Z"
- content="""
-You linked to https://wwwjscuttlebutt.nz/ but the domain seems to be misconfigured (@ not properly set and still pointing at the providers default), so the redirect that's probably there doesn't work correctly.
-https://www.scuttlebutt.nz/ Seems fine though.
-"""]]

correct spelling mistakes
diff --git a/blog/entry/DIY_professional_grade_solar_panel_installation.mdwn b/blog/entry/DIY_professional_grade_solar_panel_installation.mdwn
index 08494ac7..1794a77f 100644
--- a/blog/entry/DIY_professional_grade_solar_panel_installation.mdwn
+++ b/blog/entry/DIY_professional_grade_solar_panel_installation.mdwn
@@ -17,7 +17,7 @@ I had three goals for this install:
    power all the time.
 
 My main concerns were, would I be able to find the rafters when installing
-the rails, and would the 5x3 foot panels be too unweildly to get up on the
+the rails, and would the 5x3 foot panels be too unwieldy to get up on the
 roof by myself.
 
 I was able to find the rafters, without needing a stud finder, after I
diff --git a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
index 9e4db70d..590541f3 100644
--- a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
+++ b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
@@ -28,11 +28,11 @@ for several different purposes.
 4. To support such things as headless arm boards, building customized
    images tuned for the target board and use case, that can then
    simply be copied to the board to install.
-5. Optionally, running on the installed system later, to futher customize
+5. Optionally, running on the installed system later, to further customize
    it. Starting from the same configuration that produced the installed
    system in the first place.
 
-There can be enourmous code reuse here, and improvements made for one
+There can be enormous code reuse here, and improvements made for one
 of those will often benefit all the rest as well.
 
 Once everything is handled by configuration management, all user interface
@@ -42,7 +42,7 @@ requirements become just a matter of editing the configuration. Including:
   input is needed to install to the target system. This is really just
   a config editor underneath. I built a [[devblog/prototype_gamified_interface]]
   that's as minimal as such an interface could get.
-* With a regular text editor, of course. This is the equivilant of
+* With a regular text editor, of course. This is the equivalent of
   preseeding in d-i, giving advanced users full control over the system
   that gets built. Unlike with preseeding, users have the full power of a
   configuration management system, so can specify precisely the system they