Recent changes to this wiki:

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

fix links
diff --git a/blog/entry/extending_Scuttlebutt_with_Annah.mdwn b/blog/entry/extending_Scuttlebutt_with_Annah.mdwn
index f608cbc7..cca6e439 100644
--- a/blog/entry/extending_Scuttlebutt_with_Annah.mdwn
+++ b/blog/entry/extending_Scuttlebutt_with_Annah.mdwn
@@ -2,7 +2,7 @@ This post has it all. Flotillas of sailboats, peer-to-peer wikis, games,
 and de-frogging. But, I need to start by talking about some tech you may not
 have heard of yet...
 
-* [Scuttlebutt](https://scuttlebutt.nz/) is way for friends to share feeds
+* [Scuttlebutt](https://www.scuttlebutt.nz/) is way for friends to share feeds
   of content-addressed messages, peer-to-peer. Most Scuttlebutt clients
   currently look something like facebook, but there are also github clones,
   chess games, etc. Many private encrypted conversations going on.
diff --git a/blog/entry/saved_my_atari_programs.mdwn b/blog/entry/saved_my_atari_programs.mdwn
index fabce4d8..9ebe4eb7 100644
--- a/blog/entry/saved_my_atari_programs.mdwn
+++ b/blog/entry/saved_my_atari_programs.mdwn
@@ -1,7 +1,7 @@
 I got a SIO2PC cable for my [[atari]], hooked it up to a linux box, and used
 the atarisio tools to rip a few of my old BASIC disks. Now I can load them
 in the atari800 emulator, and will hopefully never lose this early code --
-cuz it's in [subversion^Wgit](http://git.joeyh.name/?p=joey/src.git;a=tree;f=misc/atari/disks)
+cuz it's in [git](https://git.joeyh.name/index.cgi/joey/src.git/tree/misc/atari/disks)
 now.
 
 The first disk I rescued ("finished programs disk 1") has a nice little

Added a comment: Broken Link
diff --git a/blog/entry/extending_Scuttlebutt_with_Annah/comment_1_2f961925857d162d639186c22960e0b7._comment b/blog/entry/extending_Scuttlebutt_with_Annah/comment_1_2f961925857d162d639186c22960e0b7._comment
new file mode 100644
index 00000000..57c04e4a
--- /dev/null
+++ b/blog/entry/extending_Scuttlebutt_with_Annah/comment_1_2f961925857d162d639186c22960e0b7._comment
@@ -0,0 +1,10 @@
+[[!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.
+"""]]

post
diff --git a/blog/entry/extending_Scuttlebutt_with_Annah.mdwn b/blog/entry/extending_Scuttlebutt_with_Annah.mdwn
index d6124512..f608cbc7 100644
--- a/blog/entry/extending_Scuttlebutt_with_Annah.mdwn
+++ b/blog/entry/extending_Scuttlebutt_with_Annah.mdwn
@@ -7,7 +7,7 @@ have heard of yet...
   currently look something like facebook, but there are also github clones,
   chess games, etc. Many private encrypted conversations going on.
   All entirely decentralized.  
-  (My scuttlebutt feed can be viewed [here](https://viewer.scuttlebot.io/@BCM6DHYJvWzwWi1lFl2tjDXjaqyZAEmJH5ZONSpXhtc=.ed25519)
+  (My scuttlebutt feed can be viewed [here](https://viewer.scuttlebot.io/@BCM6DHYJvWzwWi1lFl2tjDXjaqyZAEmJH5ZONSpXhtc=.ed25519))
 
 * [Annah](https://hackage.haskell.org/package/annah) is a purely
   functional, strongly typed language. Its design allows individual atoms
@@ -209,5 +209,5 @@ with Scuttlebutt will comprehensively avoid those problems. Shall we build it?
 
 ----
 
-This design work was sponsored by Jake Vosloo on
+This exploration was sponsored by Jake Vosloo on
 [Patreon](https://patreon.com/joeyh).

aspeall
diff --git a/blog/entry/extending_Scuttlebutt_with_Annah.mdwn b/blog/entry/extending_Scuttlebutt_with_Annah.mdwn
index f39994d0..d6124512 100644
--- a/blog/entry/extending_Scuttlebutt_with_Annah.mdwn
+++ b/blog/entry/extending_Scuttlebutt_with_Annah.mdwn
@@ -98,7 +98,7 @@ support for different types of Annah programs...
   frog-related memes in my Scuttlebutt client. I can write a
   Annah program that calculates a message's frogginess, and outputs a
   `Filtered Message`. It can leave a message unchanged, or filter it out,
-  or perhaps mimimize its display. I publish the Annah program on my feed,
+  or perhaps minimize its display. I publish the Annah program on my feed,
   and tell my Scuttlebutt client to filter all messages through it before
   displaying them to me.
   
@@ -157,9 +157,9 @@ support for different types of Annah programs...
   for messages containing a `ChessMove`, and builds up a description
   of the chess board.
 
-  As well as the peices on the game board, the game board description
+  As well as the pieces on the game board, the game board description
   includes Annah functions that get called when the user moves a
-  game peice. That generates a new `ChessMove` which gets recorded
+  game piece. That generates a new `ChessMove` which gets recorded
   in the user's Scuttlebutt feed.
 
   This could support a wide variety of board games. If you don't mind the
@@ -168,7 +168,7 @@ support for different types of Annah programs...
   could be built. Also there can be games like Core Wars where the gamers
   themselves write Annah programs to run inside the game.
 
-  Varients of games can be developed by modifying and reusing game
+  Variants of games can be developed by modifying and reusing game
   programs. For example, timed chess is just the chess program
   with an added check on move time, and time clock display.
 

blog update
diff --git a/blog/entry/extending_Scuttlebutt_with_Annah.mdwn b/blog/entry/extending_Scuttlebutt_with_Annah.mdwn
new file mode 100644
index 00000000..f39994d0
--- /dev/null
+++ b/blog/entry/extending_Scuttlebutt_with_Annah.mdwn
@@ -0,0 +1,213 @@
+This post has it all. Flotillas of sailboats, peer-to-peer wikis, games,
+and de-frogging. But, I need to start by talking about some tech you may not
+have heard of yet...
+
+* [Scuttlebutt](https://scuttlebutt.nz/) is way for friends to share feeds
+  of content-addressed messages, peer-to-peer. Most Scuttlebutt clients
+  currently look something like facebook, but there are also github clones,
+  chess games, etc. Many private encrypted conversations going on.
+  All entirely decentralized.  
+  (My scuttlebutt feed can be viewed [here](https://viewer.scuttlebot.io/@BCM6DHYJvWzwWi1lFl2tjDXjaqyZAEmJH5ZONSpXhtc=.ed25519)
+
+* [Annah](https://hackage.haskell.org/package/annah) is a purely
+  functional, strongly typed language. Its design allows individual atoms
+  of the language to be put in content-addressed storage, right down to
+  data types. So the value `True` and a hash of the definition of what
+  `True` is can both be treated the same by Annah's compiler.  
+  (Not to be confused with my sister, Anna, or part of the Debian Installer
+  with the same name that I wrote long ago.)
+
+So, how could these be combined together, and what might the result look
+like?
+
+Well, I could start by posting a Scuttlebutt message that [defines what
+True is](http://sigil.place/prelude/annah/1.0/Bool/True). And another
+Scuttlebutt message defining
+[False](http://sigil.place/prelude/annah/1.0/Bool/False). And then,
+another Scuttlebutt message to
+[define the AND function](http://sigil.place/prelude/annah/1.0/Bool/and),
+which would link to my messages for `True` and `False`. Continue this until
+I've built up enough Annah code to write some almost useful programs.
+
+Annah can't do any IO on its own (though it can model IO similarly to how
+Haskell does), so for programs to be actually useful, there needs to be
+Scuttlebutt client support. The way typing works in Annah, a program's type
+can be expressed as a Scuttlebutt link. So a Scuttlebutt client that wants
+to run Annah programs of a particular type can pick out programs that link
+to that type, and will know what type of data the program consumes and
+produces.
+
+Here are a few ideas of what could be built, with fairly simple client-side
+support for different types of Annah programs...
+
+* **Shared dashboards.**
+  [Boats in a flotilla are communicating via Scuttlebutt](https://viewer.scuttlebot.io/%25WPDqs%2FYnkPgjpGJrx36%2FoXgPHnmy6Ket29K4jMyVHyQ%3D.sha256),
+  and want to share a map of their planned courses. Coders collaborating
+  via Scuttlebutt want to see an overview of the state of their project.
+
+  For this, the Scuttlebutt client needs a way to run a selected Annah
+  program of type `Dashboard`, and display its output like a Scuttlebutt
+  message, in a dashboard window. The dashboard message gets updated
+  whenever other Scuttlebutt messages come in. The Annah program picks out
+  the messages it's interested in, and generates the dashboard message.
+
+  So, send a message updating your boat's position, and everyone sees it
+  update on the map. Send a message with updated weather forecasts as
+  they're received, and everyone can see the storm developing.
+  Send another message updating a waypoint to avoid the storm,
+  and steady as you go...
+
+  The coders, meanwhile, probably tweak their dashboard's code every day.
+  As they add git-ssb repos, they make the dashboard display an
+  overview of their bugs. They get CI systems hooked in and feeding
+  messages to Scuttlebutt, and make the dashboard go green or red. They
+  make the dashboard A-B test itself to pick the right shade of red.
+  And so on...
+
+  The dashboard program is stored in Scuttlebutt so everyone is on the same
+  page, and the most recent version of it posted by a team member gets
+  used. (Just have the old version of the program notice when there's a
+  newer version, and run that one..)
+
+  (Also could be used in disaster response scenarios, where the data
+  and visualization tools get built up on the fly in response to local needs,
+  and are shared peer-to-peer in areas without internet.)
+
+* **Smart hyperlinks.** When a hyperlink in a Scuttlebutt message points to a
+  Annah program, optionally with some Annah data, clicking on it can
+  run the program and display the messages that the program generates.
+
+  This is the most basic way a Scuttlebutt client could support Annah
+  programs, and it could be used for tons of stuff. A few examples:
+
+  * **Hiding spoilers.**
+    Click on the link and it'll display a spoiler about a book/movie.
+  * **A link to whatever I was talking about one year ago today.**
+    That opens different messages as time goes by. Put it in your Scuttlebutt
+    profile or something. (Requires a way for Annah to get the current
+    date, which it normally has no way of accessing.)
+  * **Choose your own adventure or twine style games.**
+    Click on the link and the program starts the game, displaying
+    links to choose between, and so on.
+  * **Links to custom views.**
+    For example, a link could lead to a combination of messages from
+    several different, related channels. Or could filter messages in some
+    way.
+
+* **Collaborative filtering.** Suppose I don't want to see
+  frog-related memes in my Scuttlebutt client. I can write a
+  Annah program that calculates a message's frogginess, and outputs a
+  `Filtered Message`. It can leave a message unchanged, or filter it out,
+  or perhaps mimimize its display. I publish the Annah program on my feed,
+  and tell my Scuttlebutt client to filter all messages through it before
+  displaying them to me.
+  
+  I published the program in my Scuttlebutt feed, and so my friends
+  can use it too. They can build other filtering functions for other 
+  stuff (such an an excess of orange in photos), and integrate my
+  frog filter into their filter program by simply composing the two.
+  
+  If I like their filter, I can switch my client to using it. Or not.
+  Filtering is thus subjective, like Scuttlebutt, and the subjectivity is
+  expressed by picking the filter you want to use, or developing a
+  better one.
+
+* **Wiki pages.** Scuttlebutt is built on immutable append-only logs; it
+  doesn't have editable wiki pages. But they can be built on top using
+  Annah.
+
+  A smart link to a wiki page is a reference to the Annah program
+  that renders it. Of course being a wiki, there will be more smart
+  links on the wiki page going to other wiki pages, and so on.
+  
+  The wiki page includes a smart link to edit it. The editor needs basic
+  form support in the Scuttlebutt client; when the edited wiki page is
+  posted, the Annah program diffs it against the previous version and
+  generates an `Edit` which gets posted to the user's feed. Rendering the
+  page is just a matter of finding the `Edit` messages for it from
+  people who are allowed to edit it, and combining them.
+
+  Anyone can fork a wiki page by posting an `Edit` to their feed. And can
+  then post a smart link to their fork of the page.
+
+  And anyone can merge other forks into their wiki page (this posts a
+  control message that makes the Annah program implementing the wiki accept
+  those forks' `Edit` messages). Or grant other users permission to edit
+  the wiki page (another control message). Or grant other users
+  permissions to grant other users permissions.
+
+  There are lots of different ways you might want your wiki to work.
+  No one wiki implementation, but lots of Annah programs. Others
+  can interact with your wiki using the program you picked, or fork it and
+  even switch the program used. Subjectivity again.
+
+* **User-defined board games.** The Scuttlebutt client finds
+  Scuttlebutt messages containing Annah programs of type `Game`,
+  and generates a tab with a list of available games.
+  
+  The players of a particular game all experience the same game interface,
+  because the code for it is part of their shared Scuttlebutt message pool,
+  and the code to use gets agreed on at the start of a game.
+
+  To play a game, the Scuttlebutt client runs the Annah program, which
+  generates a description of the current contents of the game board.
+  
+  So, for chess, use Annah to define a `ChessMove` data type,
+  and the Annah program takes the feeds of the two players, looks
+  for messages containing a `ChessMove`, and builds up a description
+  of the chess board.
+
+  As well as the peices on the game board, the game board description
+  includes Annah functions that get called when the user moves a
+  game peice. That generates a new `ChessMove` which gets recorded
+  in the user's Scuttlebutt feed.
+
+  This could support a wide variety of board games. If you don't mind the
+  possibility that your opponent might cheat by peeking at the random seed,
+  even games involving things like random card shuffles and dice rolls
+  could be built. Also there can be games like Core Wars where the gamers
+  themselves write Annah programs to run inside the game.
+
+  Varients of games can be developed by modifying and reusing game
+  programs. For example, timed chess is just the chess program
+  with an added check on move time, and time clock display.
+
+* **Decentralized chat bots.** Chat bots are all the rage (or were a few
+  months ago, tech fads move fast), but in a decentralized system like
+  Scuttlebutt, a bot running on a server somewhere would be a ugly point
+  of centralization. Instead, write a Annah program for the bot.
+
+  To launch the bot, publish a message in your own personal Scuttlebutt
+  feed that contains the bot's program, and a nonce.
+
+  The user's Scuttlebutt client takes care of the rest. It looks for messages
+  with bot programs, and runs the bot's program. This generates or updates
+  a Scuttlebutt message feed for the bot.
+
+  The bot's program signs the messages in its feed using a private key
+  that's generated by combining the user's public key, and the bot's nonce.
+  So, the bot has one feed per user it talks to, with deterministic
+  content, which avoids a problem with forking a Scuttlebutt feed.
+  
+  The bot-generated messages can be stored in the Scuttlebutt database like any
+  other messages and replicated around. The bot appears as if it were a
+  Scuttlebutt user. But you can have conversations with it while you're

(Diff truncated)
add
diff --git a/code.mdwn b/code.mdwn
index 104c3e30..6eee33d1 100644
--- a/code.mdwn
+++ b/code.mdwn
@@ -17,6 +17,7 @@ The stuff that's swapped into my local cache at the moment.
 [[ikiwiki-hosting]]
 [[github-backup]]
 [[shell-monad]]
+[[scuttlebutt-types]]
 
 ## Less active projects
 
diff --git a/code/scuttlebutt-types.mdwn b/code/scuttlebutt-types.mdwn
new file mode 100644
index 00000000..4286a7cf
--- /dev/null
+++ b/code/scuttlebutt-types.mdwn
@@ -0,0 +1,3 @@
+generic types for Secure Scuttlebutt in Haskell
+
+<http://hackage.haskell.org/package/scuttlebutt-types>

devblog
diff --git a/devblog/haskell-scuttlebutt-types.mdwn b/devblog/haskell-scuttlebutt-types.mdwn
new file mode 100644
index 00000000..8552c9e2
--- /dev/null
+++ b/devblog/haskell-scuttlebutt-types.mdwn
@@ -0,0 +1,20 @@
+Built a new haskell library, <http://hackage.haskell.org/package/scuttlebutt-types>
+
+I've been using [Secure Scuttlebutt](http://scuttlebutt.nz/) for 6 months
+or so, and think it's a rather good peer-to-peer social network. But it's very
+Javascript centric, and I want to be able to play with its data from Haskell.
+
+The scuttlebutt-types library is based on some
+[earlier work](https://github.com/bkil-syslogng/haskell-scuttlebutt)
+by Peter Hajdu. I expanded it to be have all the core Scuttlebutt data
+types, and got it parsing most of the corpus of Scuttlebutt messages.
+That took most of yesterday and all of today. The next thing to tackle
+would be generating JSON for messages formatted so the network accepts it.
+
+I don't know what scuttlebutt-types will be used for. Maybe looking up
+stats, or building bots, or perhaps even a Scuttlebutt client? We'll
+see..
+
+---
+
+Today's work was sponsored by Trenton Cronholm on Patreon.

correct spelling mistakes
diff --git a/devblog/debug_me_client-server_working.mdwn b/devblog/debug_me_client-server_working.mdwn
index b0bd5089..a2f25f12 100644
--- a/devblog/debug_me_client-server_working.mdwn
+++ b/devblog/debug_me_client-server_working.mdwn
@@ -8,7 +8,7 @@ activity at that point. A stall-free version is certianly doable, but this
 is good enough for now.
 
 There are quite a few bugs to fix. Including a security hole in the proof
-chain design, that I realized it had when thinking about what happens whith
+chain design, that I realized it had when thinking about what happens with
 multiple people are connected to a debug-me session who are all typing at
 once.
 
diff --git a/devblog/debug_me_released.mdwn b/devblog/debug_me_released.mdwn
index af34c170..a3133170 100644
--- a/devblog/debug_me_released.mdwn
+++ b/devblog/debug_me_released.mdwn
@@ -1,9 +1,9 @@
 debug-me is released! <https://debug-me.branchable.com/>
 
-I made one last protocol compatability breaking change before the release.
+I made one last protocol compatibility breaking change before the release.
 Realized that while the websocket framing protocol has a version number,
 the higher-level protocol does not, which would made extending it very hard
-later. So, added in a protocol verison number.
+later. So, added in a protocol version number.
 
 The release includes a tarball that should let debug-me run on most linux
 systems. I adapted the code from git-annex for
diff --git a/devblog/debug_me_websockets.mdwn b/devblog/debug_me_websockets.mdwn
index fd67d818..2de431ae 100644
--- a/devblog/debug_me_websockets.mdwn
+++ b/devblog/debug_me_websockets.mdwn
@@ -3,7 +3,7 @@ websockets.
 
 I decided to use the "binary" library to get an efficient serialization of
 debug-me's messages to send over the websockets, rather than using JSON.
-A typicaly JSON message was 341 bytes, and this only uses 165 bytes, which
+A typically JSON message was 341 bytes, and this only uses 165 bytes, which
 is fairly close to the actual data size of ~129 bytes. I may later use
 protocol buffers to make it less of a haskell-specific wire format.
 
diff --git a/devblog/propellor_self_bootstrap_property.mdwn b/devblog/propellor_self_bootstrap_property.mdwn
index 08303459..a4fe0565 100644
--- a/devblog/propellor_self_bootstrap_property.mdwn
+++ b/devblog/propellor_self_bootstrap_property.mdwn
@@ -19,7 +19,7 @@ I was able to reuse Propellor.Bootstrap to bootstrap propellor inside the
 chroot, which was nice. 
 
 Also nice that I'm able to work on this kind of thing at home despite it
-involving building chroots -- yay for satelite internet!
+involving building chroots -- yay for satellite internet!
 
 ----
 

layout
diff --git a/meta.mdwn b/meta.mdwn
index d6301a29..ad2ac144 100644
--- a/meta.mdwn
+++ b/meta.mdwn
@@ -6,7 +6,7 @@ pages="*/Discussion"]] are Discussion pages.
 It has a [[license]], if you care about that sort of thing. 
 
 And yeah, it's a wiki, but only Joey can edit it directly. However, you can
-clone its git repo from <git://joeyh.branchable.com/> and make changes and
+clone its git repo from `git://joeyh.branchable.com/` and make changes and
 even send me patches!
 
 Broken links:

update
diff --git a/meta.mdwn b/meta.mdwn
index 0f04ea45..d6301a29 100644
--- a/meta.mdwn
+++ b/meta.mdwn
@@ -3,7 +3,11 @@ This wiki contains [[!pagecount pages="* and !*.* and !grep/* and
 !*/Discussion"]] pages are blog entries and [[!pagecount
 pages="*/Discussion"]] are Discussion pages.
 
-It has a [[license]], if you care about that sort of thing.
+It has a [[license]], if you care about that sort of thing. 
+
+And yeah, it's a wiki, but only Joey can edit it directly. However, you can
+clone its git repo from <git://joeyh.branchable.com/> and make changes and
+even send me patches!
 
 Broken links:
 

Added a comment: Great Idea!
diff --git a/blog/entry/12_to_24_volt_house_conversion/comment_2_f29c544770495515325c891a7379a7bf._comment b/blog/entry/12_to_24_volt_house_conversion/comment_2_f29c544770495515325c891a7379a7bf._comment
new file mode 100644
index 0000000..359bece
--- /dev/null
+++ b/blog/entry/12_to_24_volt_house_conversion/comment_2_f29c544770495515325c891a7379a7bf._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="macdanny@a72b4b40c458ead665c8c2a022d209508e1393d6"
+ nickname="macdanny"
+ avatar="http://cdn.libravatar.org/avatar/e5831ecad78c64463fca51fddc891aad"
+ subject="Great Idea!"
+ date="2017-08-23T07:29:29Z"
+ content="""
+Hey Joey, Thanks for the unintended push in the right direction. I've been following along for a little while now. I recently had the cooling fan in my UPS take a nose dive. Trouble is that the UPS is 24V and those little fans are costly (especially from the UPS manufacturer). It wasn't until reading this entry that it occurred to me. I have a pile of LM317 IC's I purchased years ago for a lighting project. I used one of them to build a small circuit that allowed me to use a 12 volt fan like this one ( <a href=\"https://www.12volt-travel.com/small-12-volt-fan-for-electronics-airflow-cooling-p-23647.html\">https://www.12volt-travel.com/small-12-volt-fan-for-electronics-airflow-cooling-p-23647.html</a> ) instead of a 24 volt fan. For R2 in the circuit I added a thermistor so the fan runs slower when the UPS is cooler, but speeds up when the UPS is charging and creating more heat. So far so good. Thanks again, Dan McEntire 
+"""]]

removed
diff --git a/blog/entry/12_to_24_volt_house_conversion/comment_2_de4bd6da79dbb324d2420373efa1c693._comment b/blog/entry/12_to_24_volt_house_conversion/comment_2_de4bd6da79dbb324d2420373efa1c693._comment
deleted file mode 100644
index 4aac8ec..0000000
--- a/blog/entry/12_to_24_volt_house_conversion/comment_2_de4bd6da79dbb324d2420373efa1c693._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="macdanny@a72b4b40c458ead665c8c2a022d209508e1393d6"
- nickname="macdanny"
- avatar="http://cdn.libravatar.org/avatar/e5831ecad78c64463fca51fddc891aad"
- subject="Great Idea!"
- date="2017-08-22T17:27:03Z"
- content="""
-Hey Joey, Thanks for the unintended push in the right direction. I've been following along for a little while now. I recently had the cooling fan in my UPS take a nose dive. Trouble is that the UPS is 24V and those little fans are costly (especially from the UPS manufacturer). It wasn't until reading this entry that it occurred to me. I have a pile of LM317 IC's I purchased years ago for a lighting project. I used one of them to build a small circuit that allowed me to use a 12 volt fan like this one ( https://www.12volt-travel.com/small-12-volt-fan-for-electronics-airflow-cooling-p-23647.html ) instead of a 24 volt fan. For R2 in the circuit I added a thermistor so the fan runs slower when the UPS is cooler, but speeds up when the UPS is charging and creating more heat. So far so good. Thanks again, Dan McEntire
-"""]]

Added a comment: Great Idea!
diff --git a/blog/entry/12_to_24_volt_house_conversion/comment_2_de4bd6da79dbb324d2420373efa1c693._comment b/blog/entry/12_to_24_volt_house_conversion/comment_2_de4bd6da79dbb324d2420373efa1c693._comment
new file mode 100644
index 0000000..4aac8ec
--- /dev/null
+++ b/blog/entry/12_to_24_volt_house_conversion/comment_2_de4bd6da79dbb324d2420373efa1c693._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="macdanny@a72b4b40c458ead665c8c2a022d209508e1393d6"
+ nickname="macdanny"
+ avatar="http://cdn.libravatar.org/avatar/e5831ecad78c64463fca51fddc891aad"
+ subject="Great Idea!"
+ date="2017-08-22T17:27:03Z"
+ content="""
+Hey Joey, Thanks for the unintended push in the right direction. I've been following along for a little while now. I recently had the cooling fan in my UPS take a nose dive. Trouble is that the UPS is 24V and those little fans are costly (especially from the UPS manufacturer). It wasn't until reading this entry that it occurred to me. I have a pile of LM317 IC's I purchased years ago for a lighting project. I used one of them to build a small circuit that allowed me to use a 12 volt fan like this one ( https://www.12volt-travel.com/small-12-volt-fan-for-electronics-airflow-cooling-p-23647.html ) instead of a 24 volt fan. For R2 in the circuit I added a thermistor so the fan runs slower when the UPS is cooler, but speeds up when the UPS is charging and creating more heat. So far so good. Thanks again, Dan McEntire
+"""]]

link img to video
diff --git a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
index f6fc714..9e4db70 100644
--- a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
+++ b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
@@ -14,7 +14,7 @@ and perform the installation. The whole demo took around 20 minutes,
 and ended with a standard Debian desktop installation.
 ([Video](http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/life-after-debian.vp8.webm))
 
-[[!img pics/debconf/17/debconf17.png]]
+[[!img pics/debconf/17/debconf17.png link="http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/life-after-debian.vp8.webm"]]
 
 The core idea is to reuse the same configuration management system 
 for several different purposes.

correction
diff --git a/talks.mdwn b/talks.mdwn
index 76b14c8..d0c2d0e 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -113,3 +113,5 @@ by others.
 * "Life After Debian"
   - [video](http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/life-after-debian.vp8.webm)
   - [[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.

add pic and tag
diff --git a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
index a87bcfc..f6fc714 100644
--- a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
+++ b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
@@ -14,6 +14,8 @@ and perform the installation. The whole demo took around 20 minutes,
 and ended with a standard Debian desktop installation.
 ([Video](http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/life-after-debian.vp8.webm))
 
+[[!img pics/debconf/17/debconf17.png]]
+
 The core idea is to reuse the same configuration management system 
 for several different purposes.
 
@@ -94,3 +96,5 @@ ideas encountered along the way:
   [[dependency yak shaving|devblog/yak_attack]], 
   [[devblog/high_bandwidth_propellor_hacking]]
   and [[finishing_touches|devblog/secret_project_its_aliiive]]
+
+[[!tag propellor]]
diff --git a/pics/debconf/17/debconf17.png b/pics/debconf/17/debconf17.png
new file mode 100644
index 0000000..5d37f4f
Binary files /dev/null and b/pics/debconf/17/debconf17.png differ

talk available; add slides
diff --git a/talks.mdwn b/talks.mdwn
index 6cfad6f..76b14c8 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -111,5 +111,5 @@ by others.
 ## DebConf 17, Montreal, Canada
 
 * "Life After Debian"
-  - August 8th, 6:00 pm
-  - [abstract](https://debconf17.debconf.org/talks/21/)
+  - [video](http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/life-after-debian.vp8.webm)
+  - [[slides|debconf-17-life-after-debian.pdf]]
diff --git a/talks/debconf-17-life-after-debian.pdf b/talks/debconf-17-life-after-debian.pdf
new file mode 100644
index 0000000..d29019c
Binary files /dev/null and b/talks/debconf-17-life-after-debian.pdf differ

link to recording
diff --git a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
index c79268e..a87bcfc 100644
--- a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
+++ b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
@@ -12,6 +12,7 @@ from the audience to
 [play with its visual user interface](https://downloads.kitenet.net/videos/prototype_gamified_interface.webm) 
 and perform the installation. The whole demo took around 20 minutes,
 and ended with a standard Debian desktop installation.
+([Video](http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/life-after-debian.vp8.webm))
 
 The core idea is to reuse the same configuration management system 
 for several different purposes.

expand
diff --git a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
index 12fef1c..c79268e 100644
--- a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
+++ b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
@@ -36,15 +36,17 @@ Once everything is handled by configuration management, all user interface
 requirements become just a matter of editing the configuration. Including:
 
 * A user interface that runs on the live system and gets whatever
-   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.
+  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
-   preseeding in d-i, giving advanced users full control over the system
-   that gets built.
+  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
+  want installed.
 * A separate user interface for customizing disk images, for arm
-   boards and similar use cases. This would run on a server,
-   or on the user's own laptop.
+  boards and similar use cases. This would run on a server,
+  or on the user's own laptop.
 
 That's the gist of it. Configuration management reused for installation
 and image building, and multiple editor interfaces to make it widely

bullets
diff --git a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
index 92fc4c3..12fef1c 100644
--- a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
+++ b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
@@ -35,14 +35,14 @@ of those will often benefit all the rest as well.
 Once everything is handled by configuration management, all user interface
 requirements become just a matter of editing the configuration. Including:
 
-1. A user interface that runs on the live system and gets whatever
+* A user interface that runs on the live system and gets whatever
    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.
-2. With a regular text editor, of course. This is the equivilant of
+* With a regular text editor, of course. This is the equivilant of
    preseeding in d-i, giving advanced users full control over the system
    that gets built.
-3. A separate user interface for customizing disk images, for arm
+* A separate user interface for customizing disk images, for arm
    boards and similar use cases. This would run on a server,
    or on the user's own laptop.
 

update
diff --git a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
index 5074973..92fc4c3 100644
--- a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
+++ b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
@@ -13,7 +13,7 @@ from the audience to
 and perform the installation. The whole demo took around 20 minutes,
 and ended with a standard Debian desktop installation.
 
-The idea is to reuse the same configuration management system 
+The core idea is to reuse the same configuration management system 
 for several different purposes.
 
 1. Building a bootable disk image that can be used as both a live system

final
diff --git a/blog/entry/building_a_Debian_installer_with_propellor.mdwn b/blog/entry/building_a_Debian_installer_with_propellor.mdwn
deleted file mode 100644
index 9746dc0..0000000
--- a/blog/entry/building_a_Debian_installer_with_propellor.mdwn
+++ /dev/null
@@ -1,168 +0,0 @@
-Three years ago, I realized that [[code/propellor]] (my configuration
-management system that is configured using haskell) could be used as an
-installer for Debian (or other versions of Linux). In
-[[propellor_is_d-i_2.0]], I guessed it would take "a month and adding a few
-thousand lines of code". I've now taken that month, and written [that 1
-KLoC](https://git.joeyh.name/index.cgi/secret-project.git/), and I
-presented the result at DebConf yesterday.
-
-The idea is to reuse the same configuration management system 
-for several different purposes.
-
-1. Building a bootable disk image that can be used as both a live system
-   and as an installer.
-2. Running on that live system, to install the target system. Which can
-   just involve copying the live system to the target disk and then letting
-   the configuration management system make the necessary changes to get
-   from the live system configuration to the target system configuration.
-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
-   it. Starting from the same configuration that produced the installed
-   system in the first place.
-
-There's enourmous code reuse here, and improvements made for one
-will often benefit all the rest as well.
-
-Once everything is handled by configuration management, all user interface
-requirements become just a matter of editing the configuration. Including:
-
-1. A user interface that runs on the live system and gets whatever
-   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.
-2. With a regular text editor, of course. This is the equivilant of
-   preseeding in d-i, giving advanced users full control over the system
-   that gets built.
-3. A separate user interface for customizing disk images, for arm
-   boards and similar use cases. This would run on a server,
-   or on the user's own laptop.
-
-That's the gist of it. Configuration management reused for installation
-and image building, and multiple editor interfaces to make it widely
-usable.
-
-----
-
-Here's links to more details about what I built, and ideas encountered
-along the way.
-
-* In [[Functional_Reactive_Propellor]] I found a way to express the
-  commonalities and differences between the installer's configuration and
-  the target system's configuration. This lets the installer disk image
-  be copied to the target and the minimum work be done to convert it into
-  the desired target system.
-* In [[devblog/disk_partitioning_nitty_gritty]] I tackled configuring the partition
-  table of the target system. I extended a DSL propellor already used
-  for partitioning disk images.
-* In [[devblog/end_in_sight]] I found a way to make propellor
-  build disk images super fast, so a new 5 gb disk image can be ready in 30
-  seconds, a quarter of the time that it takes to write a 5 gb file with `dd`.
-* For completeness sake, I also [[devblogged|devblog]] about 
-  [[unfortunately needing a progress bar|devblog/secret_project_progress_bar]],
-  [[picking the disk to install to and installing grub|devblog/secret_project_close_but_no_cigar]],
-  [[yak shaving|devblog/yak_attack]], [[devblog/high_bandwidth_propellor_hacking]]
-  and [[finishing_touches|devblog/secret_project_its_aliiive]]
-
-----
-
-Finally, here's the propellor config file used to both build an
-installer image, and used in that installer to install the target system.
-
-First (after some `imports`) it tells propellor about two hosts, and
-runs `installerMain`, which displays the user interface when run in the
-installer.
-
-[[!format haskell """
-main :: IO ()
-main = installerMain hosts
-
-hosts :: [Host]
-hosts =
-        [ installer
-        , installer_builder
-        ]
-"""]]
-
-Then the configuration of the host that builds the installer image.
-
-[[!format haskell """
--- | This is not a complete Host definition; it can be used on any host
--- to build the installer disk images, by running, as root:
---      propellor installer.builder
-installer_builder :: Host
-installer_builder = host "installer.builder" $ props
-        & osDebian Unstable X86_64
-        & installerBuilt
-
--- | Build a disk image for the installer.
-installerBuilt :: RevertableProperty (HasInfo + DebianLike) Linux
-installerBuilt = imageBuilt "/srv/installer.img"
-        (hostChroot installer (Debootstrapped mempty))
-        MSDOS
-        [ partition EXT4 `mountedAt` "/"
-                `setFlag` BootFlag
-                `mountOpt` errorReadonly
-                `reservedSpacePercentage` 0
-                `addFreeSpace` MegaBytes 256
-        ]
-"""]]
-
-Then create a data type, so we can keep the installer and target configurations
-distinct, and derive both from a common `seed`.
-
-[[!format haskell """
-data Variety = Installer | Target
-        deriving (Eq)
-
-installer :: Host
-installer = seed `version` Installer
-
-target :: Host
-target = seed `version` Target
-"""]]
-
-And finally the seed from which it grows. Starting off with all the properties
-that the installer and target system have in common.
-
-[[!format haskell """
-seed :: Versioned Variety Host
-seed ver = host "debian.local" $ props
-        & osDebian Unstable X86_64
-        & Hostname.sane
-        & Apt.stdSourcesList
-        & Apt.installed ["linux-image-amd64"]
-        & Grub.installed PC
-        & XFCE.installed
-        & Apt.installed ["firefox"]
-        & "en_US.UTF-8" `Locale.selectedFor` ["LANG"]
-"""]]
-
-And then continuing with properties that differ between the installer
-and the target system.
-
-[[!format haskell """
-        & ver (   (== Installer) --> installerUser
-              <|> (== Target)    --> desktopUser (inputUserName userInput)
-              )
-        & ver (   (== Installer) --> autostartInstaller)
-        & ver (   (== Installer) --> targetInstalled target userInput parts)
-        & ver (   (== Target)    --> fstabLists userInput parts)
-        & ver (   (== Installer) --> targetBootable userInput)
-"""]]
-
-And finally, the partition table for the target system.
-
-[[!format haskell """
-parts = TargetPartTable MSDOS
-        [ partition EXT2 `mountedAt` "/boot"
-                `setFlag` BootFlag
-                `mountOpt` errorReadonly
-                `setSize` MegaBytes 512
-        , partition EXT4 `mountedAt` "/"
-                `mountOpt` errorReadonly
-                `useDiskSpace` RemainingSpace
-        , swapPartition (MegaBytes 1024)
-        ]
-"""]]
diff --git a/blog/entry/unifying_OS_installation_and_configuration_management.mdwn b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
new file mode 100644
index 0000000..5074973
--- /dev/null
+++ b/blog/entry/unifying_OS_installation_and_configuration_management.mdwn
@@ -0,0 +1,93 @@
+Three years ago, I realized that [[code/propellor]] (my configuration
+management system that is configured using haskell) could be used as an
+installer for Debian (or other versions of Linux). In
+[[propellor_is_d-i_2.0]], I guessed it would take "a month and adding a few
+thousand lines of code". 
+
+I've now taken that month, and written 
+[that code](https://git.joeyh.name/index.cgi/secret-project.git/), and I
+presented the result at DebConf yesterday. I demoed propellor building
+a live Debian installation image, and then handed it off to a volenteer
+from the audience to 
+[play with its visual user interface](https://downloads.kitenet.net/videos/prototype_gamified_interface.webm) 
+and perform the installation. The whole demo took around 20 minutes,
+and ended with a standard Debian desktop installation.
+
+The idea is to reuse the same configuration management system 
+for several different purposes.
+
+1. Building a bootable disk image that can be used as both a live system
+   and as an OS installer.

(Diff truncated)
layout
diff --git a/blog/entry/building_a_Debian_installer_with_propellor.mdwn b/blog/entry/building_a_Debian_installer_with_propellor.mdwn
index bbda39c..9746dc0 100644
--- a/blog/entry/building_a_Debian_installer_with_propellor.mdwn
+++ b/blog/entry/building_a_Debian_installer_with_propellor.mdwn
@@ -137,7 +137,7 @@ seed ver = host "debian.local" $ props
         & XFCE.installed
         & Apt.installed ["firefox"]
         & "en_US.UTF-8" `Locale.selectedFor` ["LANG"]
-""]]
+"""]]
 
 And then continuing with properties that differ between the installer
 and the target system.

layout
diff --git a/blog/entry/building_a_Debian_installer_with_propellor.mdwn b/blog/entry/building_a_Debian_installer_with_propellor.mdwn
index 32d96b8..bbda39c 100644
--- a/blog/entry/building_a_Debian_installer_with_propellor.mdwn
+++ b/blog/entry/building_a_Debian_installer_with_propellor.mdwn
@@ -112,7 +112,7 @@ installerBuilt = imageBuilt "/srv/installer.img"
 Then create a data type, so we can keep the installer and target configurations
 distinct, and derive both from a common `seed`.
 
-[[[!format haskell """
+[[!format haskell """
 data Variety = Installer | Target
         deriving (Eq)
 
@@ -126,7 +126,7 @@ target = seed `version` Target
 And finally the seed from which it grows. Starting off with all the properties
 that the installer and target system have in common.
 
-[[[!format haskell """
+[[!format haskell """
 seed :: Versioned Variety Host
 seed ver = host "debian.local" $ props
         & osDebian Unstable X86_64
@@ -142,7 +142,7 @@ seed ver = host "debian.local" $ props
 And then continuing with properties that differ between the installer
 and the target system.
 
-[[[!format haskell """
+[[!format haskell """
         & ver (   (== Installer) --> installerUser
               <|> (== Target)    --> desktopUser (inputUserName userInput)
               )
@@ -154,7 +154,7 @@ and the target system.
 
 And finally, the partition table for the target system.
 
-[[[!format haskell """
+[[!format haskell """
 parts = TargetPartTable MSDOS
         [ partition EXT2 `mountedAt` "/boot"
                 `setFlag` BootFlag

layout
diff --git a/blog/entry/building_a_Debian_installer_with_propellor.mdwn b/blog/entry/building_a_Debian_installer_with_propellor.mdwn
index d596cd0..32d96b8 100644
--- a/blog/entry/building_a_Debian_installer_with_propellor.mdwn
+++ b/blog/entry/building_a_Debian_installer_with_propellor.mdwn
@@ -87,7 +87,7 @@ hosts =
 
 Then the configuration of the host that builds the installer image.
 
-[[[!format haskell """
+[[!format haskell """
 -- | This is not a complete Host definition; it can be used on any host
 -- to build the installer disk images, by running, as root:
 --      propellor installer.builder

layout
diff --git a/blog/entry/building_a_Debian_installer_with_propellor.mdwn b/blog/entry/building_a_Debian_installer_with_propellor.mdwn
index 9befcad..d596cd0 100644
--- a/blog/entry/building_a_Debian_installer_with_propellor.mdwn
+++ b/blog/entry/building_a_Debian_installer_with_propellor.mdwn
@@ -54,8 +54,8 @@ along the way.
   be copied to the target and the minimum work be done to convert it into
   the desired target system.
 * In [[devblog/disk_partitioning_nitty_gritty]] I tackled configuring the partition
-  table of the target system. I extended the DSL used for 
-  configuring disk image partitioning.
+  table of the target system. I extended a DSL propellor already used
+  for partitioning disk images.
 * In [[devblog/end_in_sight]] I found a way to make propellor
   build disk images super fast, so a new 5 gb disk image can be ready in 30
   seconds, a quarter of the time that it takes to write a 5 gb file with `dd`.
@@ -74,7 +74,7 @@ First (after some `imports`) it tells propellor about two hosts, and
 runs `installerMain`, which displays the user interface when run in the
 installer.
 
-[[!language haskell """
+[[!format haskell """
 main :: IO ()
 main = installerMain hosts
 
@@ -87,7 +87,7 @@ hosts =
 
 Then the configuration of the host that builds the installer image.
 
-[[[!language haskell """
+[[[!format haskell """
 -- | This is not a complete Host definition; it can be used on any host
 -- to build the installer disk images, by running, as root:
 --      propellor installer.builder
@@ -112,7 +112,7 @@ installerBuilt = imageBuilt "/srv/installer.img"
 Then create a data type, so we can keep the installer and target configurations
 distinct, and derive both from a common `seed`.
 
-[[[!language haskell """
+[[[!format haskell """
 data Variety = Installer | Target
         deriving (Eq)
 
@@ -126,7 +126,7 @@ target = seed `version` Target
 And finally the seed from which it grows. Starting off with all the properties
 that the installer and target system have in common.
 
-[[[!language haskell """
+[[[!format haskell """
 seed :: Versioned Variety Host
 seed ver = host "debian.local" $ props
         & osDebian Unstable X86_64
@@ -142,7 +142,7 @@ seed ver = host "debian.local" $ props
 And then continuing with properties that differ between the installer
 and the target system.
 
-[[[!language haskell """
+[[[!format haskell """
         & ver (   (== Installer) --> installerUser
               <|> (== Target)    --> desktopUser (inputUserName userInput)
               )
@@ -154,7 +154,7 @@ and the target system.
 
 And finally, the partition table for the target system.
 
-[[[!language haskell """
+[[[!format haskell """
 parts = TargetPartTable MSDOS
         [ partition EXT2 `mountedAt` "/boot"
                 `setFlag` BootFlag

-link
diff --git a/blog/entry/building_a_Debian_installer_with_propellor.mdwn b/blog/entry/building_a_Debian_installer_with_propellor.mdwn
index 3823d2f..9befcad 100644
--- a/blog/entry/building_a_Debian_installer_with_propellor.mdwn
+++ b/blog/entry/building_a_Debian_installer_with_propellor.mdwn
@@ -48,7 +48,7 @@ usable.
 Here's links to more details about what I built, and ideas encountered
 along the way.
 
-* In [[devblog/Functional_Reactive_Propellor]] I found a way to express the
+* In [[Functional_Reactive_Propellor]] I found a way to express the
   commonalities and differences between the installer's configuration and
   the target system's configuration. This lets the installer disk image
   be copied to the target and the minimum work be done to convert it into

blog update
diff --git a/blog/entry/building_a_Debian_installer_with_propellor.mdwn b/blog/entry/building_a_Debian_installer_with_propellor.mdwn
new file mode 100644
index 0000000..3823d2f
--- /dev/null
+++ b/blog/entry/building_a_Debian_installer_with_propellor.mdwn
@@ -0,0 +1,168 @@
+Three years ago, I realized that [[code/propellor]] (my configuration
+management system that is configured using haskell) could be used as an
+installer for Debian (or other versions of Linux). In
+[[propellor_is_d-i_2.0]], I guessed it would take "a month and adding a few
+thousand lines of code". I've now taken that month, and written [that 1
+KLoC](https://git.joeyh.name/index.cgi/secret-project.git/), and I
+presented the result at DebConf yesterday.
+
+The idea is to reuse the same configuration management system 
+for several different purposes.
+
+1. Building a bootable disk image that can be used as both a live system
+   and as an installer.
+2. Running on that live system, to install the target system. Which can
+   just involve copying the live system to the target disk and then letting
+   the configuration management system make the necessary changes to get
+   from the live system configuration to the target system configuration.
+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
+   it. Starting from the same configuration that produced the installed
+   system in the first place.
+
+There's enourmous code reuse here, and improvements made for one
+will often benefit all the rest as well.
+
+Once everything is handled by configuration management, all user interface
+requirements become just a matter of editing the configuration. Including:
+
+1. A user interface that runs on the live system and gets whatever
+   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.
+2. With a regular text editor, of course. This is the equivilant of
+   preseeding in d-i, giving advanced users full control over the system
+   that gets built.
+3. A separate user interface for customizing disk images, for arm
+   boards and similar use cases. This would run on a server,
+   or on the user's own laptop.
+
+That's the gist of it. Configuration management reused for installation
+and image building, and multiple editor interfaces to make it widely
+usable.
+
+----
+
+Here's links to more details about what I built, and ideas encountered
+along the way.
+
+* In [[devblog/Functional_Reactive_Propellor]] I found a way to express the
+  commonalities and differences between the installer's configuration and
+  the target system's configuration. This lets the installer disk image
+  be copied to the target and the minimum work be done to convert it into
+  the desired target system.
+* In [[devblog/disk_partitioning_nitty_gritty]] I tackled configuring the partition
+  table of the target system. I extended the DSL used for 
+  configuring disk image partitioning.
+* In [[devblog/end_in_sight]] I found a way to make propellor
+  build disk images super fast, so a new 5 gb disk image can be ready in 30
+  seconds, a quarter of the time that it takes to write a 5 gb file with `dd`.
+* For completeness sake, I also [[devblogged|devblog]] about 
+  [[unfortunately needing a progress bar|devblog/secret_project_progress_bar]],
+  [[picking the disk to install to and installing grub|devblog/secret_project_close_but_no_cigar]],
+  [[yak shaving|devblog/yak_attack]], [[devblog/high_bandwidth_propellor_hacking]]
+  and [[finishing_touches|devblog/secret_project_its_aliiive]]
+
+----
+
+Finally, here's the propellor config file used to both build an
+installer image, and used in that installer to install the target system.
+
+First (after some `imports`) it tells propellor about two hosts, and
+runs `installerMain`, which displays the user interface when run in the
+installer.
+
+[[!language haskell """
+main :: IO ()
+main = installerMain hosts
+
+hosts :: [Host]
+hosts =
+        [ installer
+        , installer_builder
+        ]
+"""]]
+
+Then the configuration of the host that builds the installer image.
+
+[[[!language haskell """
+-- | This is not a complete Host definition; it can be used on any host
+-- to build the installer disk images, by running, as root:
+--      propellor installer.builder
+installer_builder :: Host
+installer_builder = host "installer.builder" $ props
+        & osDebian Unstable X86_64
+        & installerBuilt
+
+-- | Build a disk image for the installer.
+installerBuilt :: RevertableProperty (HasInfo + DebianLike) Linux
+installerBuilt = imageBuilt "/srv/installer.img"
+        (hostChroot installer (Debootstrapped mempty))
+        MSDOS
+        [ partition EXT4 `mountedAt` "/"
+                `setFlag` BootFlag
+                `mountOpt` errorReadonly
+                `reservedSpacePercentage` 0
+                `addFreeSpace` MegaBytes 256
+        ]
+"""]]
+
+Then create a data type, so we can keep the installer and target configurations
+distinct, and derive both from a common `seed`.
+
+[[[!language haskell """
+data Variety = Installer | Target
+        deriving (Eq)
+
+installer :: Host
+installer = seed `version` Installer
+
+target :: Host
+target = seed `version` Target
+"""]]
+
+And finally the seed from which it grows. Starting off with all the properties
+that the installer and target system have in common.
+
+[[[!language haskell """
+seed :: Versioned Variety Host
+seed ver = host "debian.local" $ props
+        & osDebian Unstable X86_64
+        & Hostname.sane
+        & Apt.stdSourcesList
+        & Apt.installed ["linux-image-amd64"]
+        & Grub.installed PC
+        & XFCE.installed
+        & Apt.installed ["firefox"]
+        & "en_US.UTF-8" `Locale.selectedFor` ["LANG"]
+""]]
+
+And then continuing with properties that differ between the installer
+and the target system.
+
+[[[!language haskell """
+        & ver (   (== Installer) --> installerUser
+              <|> (== Target)    --> desktopUser (inputUserName userInput)
+              )
+        & ver (   (== Installer) --> autostartInstaller)
+        & ver (   (== Installer) --> targetInstalled target userInput parts)
+        & ver (   (== Target)    --> fstabLists userInput parts)
+        & ver (   (== Installer) --> targetBootable userInput)
+"""]]
+
+And finally, the partition table for the target system.
+
+[[[!language haskell """
+parts = TargetPartTable MSDOS
+        [ partition EXT2 `mountedAt` "/boot"
+                `setFlag` BootFlag
+                `mountOpt` errorReadonly
+                `setSize` MegaBytes 512
+        , partition EXT4 `mountedAt` "/"
+                `mountOpt` errorReadonly
+                `useDiskSpace` RemainingSpace
+        , swapPartition (MegaBytes 1024)
+        ]
+"""]]

Add overwrite and ftruncate from editing in place discussion
diff --git a/code/moreutils/discussion.mdwn b/code/moreutils/discussion.mdwn
index fbaffef..604a289 100644
--- a/code/moreutils/discussion.mdwn
+++ b/code/moreutils/discussion.mdwn
@@ -578,3 +578,8 @@ Running foo.py and then immediately exiting 'less' by pressing 'q' causes sponge
     error writing buffer to output file: Broken pipe
 
 Curiously, running bar.sh directly doesn't have this problem.  I'm not sure what Python is doing to the execution environment to cause this, but would you consider changing write_buff_out to suppress its warning spew if it's writing to stdout?
+
+## Miscellanious
+
+* [overwrite](https://unix.stackexchange.com/a/11074/176171)
+* [ftrunctate](https://unix.stackexchange.com/a/280277/176171)

blog
diff --git a/blog/entry/home_power_monitoring.mdwn b/blog/entry/home_power_monitoring.mdwn
new file mode 100644
index 0000000..af8ef30
--- /dev/null
+++ b/blog/entry/home_power_monitoring.mdwn
@@ -0,0 +1,22 @@
+For years I've recorded solar panel data by hand. Filled two notebooks
+with columns of figures. My new charge controller, an 
+[EPsolar Tracer-BN](http://www.epsolarpv.com/en/index.php/Product/pro_content/id/573/am_id/136),
+finally let me automate it.
+
+[[!img blog/pics/homepower.png caption="morning activity; by 8 am the sun is still behind the hill but, 
+16 watts are being produced, and by 11:30 am, the battery bank is full"]]
+
+You can explore my home power data here: <http://homepower.joeyh.name/>  
+(click and drag to zoom)
+
+The web interface loads the RRD files into a web browser
+using [javascriptRRD](http://javascriptrrd.sourceforge.net/).
+I wrote a [haskell program](https://git.joeyh.name/index.cgi/joey/homepower.git/tree/poller.hs)
+that drives the
+[epsolar-tracer python library](https://github.com/kasbert/epsolar-tracer)
+to poll for data, and stores it in RRD files. Could have used collectd or
+something, but the interface to the charge controller is currently
+a bit flakey and I have to be careful about retries and polling frequencies. 
+Also I wanted full control over how much data is stored in the RRD files.
+
+[Full source code](https://git.joeyh.name/index.cgi/joey/homepower.git/)
diff --git a/blog/pics/homepower.png b/blog/pics/homepower.png
new file mode 100644
index 0000000..5fa427e
Binary files /dev/null and b/blog/pics/homepower.png differ

typo
diff --git a/thanks.mdwn b/thanks.mdwn
index 0111ed0..c25d5e6 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 Patream](https://patreon.com/joeyh)
+* [support me on Patreon](https://patreon.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>

devblog
diff --git a/devblog/secret_project_progress_bar.mdwn b/devblog/secret_project_progress_bar.mdwn
new file mode 100644
index 0000000..7326d1d
--- /dev/null
+++ b/devblog/secret_project_progress_bar.mdwn
@@ -0,0 +1,12 @@
+One of my initial goals for secret-project was for it to not need to
+implement a progress bar.
+
+[[!img progressbar.png]]
+
+So, of course, today I found myself implementing a progress bar to finish
+up secret-project. As well as some other UI polishing, and fixing a couple
+of bugs in propellor that impacted it.
+
+Ok, I'm entirely done with secret-project now, except for an unveiling
+later this month. Looking back over the devblog, it took only
+around 14 days total to build it all. Feels longer, but not bad!

devblog
diff --git a/devblog/secret_project_progress_bar/progressbar.png b/devblog/secret_project_progress_bar/progressbar.png
new file mode 100644
index 0000000..417ce5e
Binary files /dev/null and b/devblog/secret_project_progress_bar/progressbar.png differ

devblog
diff --git a/devblog/secret_project_its_aliiive.mdwn b/devblog/secret_project_its_aliiive.mdwn
new file mode 100644
index 0000000..344dcc2
--- /dev/null
+++ b/devblog/secret_project_its_aliiive.mdwn
@@ -0,0 +1,14 @@
+After a rather interesting morning, the secret-project is doing exactly
+what I set out to accomplish! It's alllive!
+
+(I found a way to segfault the ghc runtime first.
+And then I also managed to crash firefox, and finally managed to crash and
+hard-hang rsync.)
+
+All that remains to be done now is to clean up the user interface.
+I made propellor's output be displayed in the web browser, but currently
+it contains ansi escape sequences which don't look good.
+
+This would probably be a bad time to implement a in-browser terminal
+emulator in haskell, and perhaps a good time to give propellor customizable
+output backends. I have 3 days left to completely finish this project.

devblog
diff --git a/devblog/secret_project_close_but_no_cigar.mdwn b/devblog/secret_project_close_but_no_cigar.mdwn
new file mode 100644
index 0000000..3df3e62
--- /dev/null
+++ b/devblog/secret_project_close_but_no_cigar.mdwn
@@ -0,0 +1,15 @@
+One last detour: Had to do more work than I really want to at this stage,
+to make the secret-project pick a good disk to use. Hardcoding a disk
+device was not working reliably enough even for a demo. Ended up with some
+fairly sophisticated heuristics to pick the right disk, taking disk size
+and media into account.
+
+Then finally got on with grub installation to the target disk. Installing
+grub to a disk from a chroot is a fiddley process hard to get right. But, I
+remembered writing similar code before; propellor installs grub to a disk
+image from a chroot. So I generalized that special-purpose code to something
+the secret-project can also use.
+
+It was a very rainy day, and rain fade on the satellite internet prevented
+me from testing it quickly. There were some dumb bugs. But at 11:30 pm,
+it Just Worked! Well, at least the target booted. /etc/fstab is not 100% right.

update
diff --git a/boxen/honeybee.mdwn b/boxen/honeybee.mdwn
index 1045a7a..2c3d604 100644
--- a/boxen/honeybee.mdwn
+++ b/boxen/honeybee.mdwn
@@ -1 +1 @@
-Cubietruck, at Anna's, used for git-annex arm autobuilder.
+Cubietruck, used as my home router and git-annex arm autobuilder.
diff --git a/talks.mdwn b/talks.mdwn
index 29ef7ac..6cfad6f 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -111,5 +111,5 @@ by others.
 ## DebConf 17, Montreal, Canada
 
 * "Life After Debian"
-  - August 10th, 3:30 pm
+  - August 8th, 6:00 pm
   - [abstract](https://debconf17.debconf.org/talks/21/)

devblog
diff --git a/devblog/end_in_sight.mdwn b/devblog/end_in_sight.mdwn
new file mode 100644
index 0000000..65747e7
--- /dev/null
+++ b/devblog/end_in_sight.mdwn
@@ -0,0 +1,25 @@
+Late Friday evening, I realized that the secret-project's user interface
+should be a specialized propellor config file editor. Eureka! With that in mind,
+I reworked how the UserInput value is passed from the UI to propellor;
+now there's a UserInput.hs module that starts out with an unconfigured
+value, and the UI rewrites that file. This has a lot of benefits, including
+being able to test it without going through the UI, and letting the UI be
+decoupled into a separate program.
+
+Also, sped up propellor's disk image building a *lot*. It already had some
+efficiency hacks, to reuse disk image files and rsync files to the disk
+image, but it was still repartitioning the disk image every time, and the
+whole raw disk image was being copied to create the vmdk file for
+VirtualBox. Now it only repartitions when something has changed, and the
+vmdk file references the disk image, which sped up the secret-project's 5
+gigabyte image build time from around 30 minutes to 30 seconds.
+
+With that procrastination^Wgroundwork complete, I was finally at the point of
+testing the secret-project running on the disk image. There were a few minor
+problems, but within an hour it was successfully partitioning, mounting,
+and populating the target disk.
+
+Still have to deal with boot loader installation and progress
+display, but the end of the secret-project is in sight.
+
+Today's work was sponsored by Trenton Cronholm on Patreon.

typ
diff --git a/home.mdwn b/home.mdwn
index 8d93cc2..2b8359c 100644
--- a/home.mdwn
+++ b/home.mdwn
@@ -7,5 +7,5 @@ Home since 2010 is...
 * No running water (hauled from two springs)
 * Total privacy (all land visible from house is mine)
 * Pretty damn isolated
-* Dialup and satelite internet
+* Dialup and satellite internet
 * Where the heart is

format
diff --git a/links/personal.mdwn b/links/personal.mdwn
index 599954d..c3b0a37 100644
--- a/links/personal.mdwn
+++ b/links/personal.mdwn
@@ -2,7 +2,7 @@
 
 [[blog]]  
 [[pics]]  
-[[home]]
+[[home]]  
 [[contact_me|contact]]  
 [[GPG key|contact]]  
 [[todo]]

home
diff --git a/home.mdwn b/home.mdwn
new file mode 100644
index 0000000..8d93cc2
--- /dev/null
+++ b/home.mdwn
@@ -0,0 +1,11 @@
+Home since 2010 is...
+
+* Offgrid
+* [[blog/Solar]] powered
+* Earth sheltered (dug 8 feet into hillside)
+* Sun and wood heated
+* No running water (hauled from two springs)
+* Total privacy (all land visible from house is mine)
+* Pretty damn isolated
+* Dialup and satelite internet
+* Where the heart is
diff --git a/links/personal.mdwn b/links/personal.mdwn
index e47b4c5..599954d 100644
--- a/links/personal.mdwn
+++ b/links/personal.mdwn
@@ -2,6 +2,7 @@
 
 [[blog]]  
 [[pics]]  
+[[home]]
 [[contact_me|contact]]  
 [[GPG key|contact]]  
 [[todo]]

talk
diff --git a/talks.mdwn b/talks.mdwn
index 47c5414..29ef7ac 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -107,3 +107,9 @@ by others.
 * "securely backing up gpg private keys.. to the cloud‽"
   - [video](https://media.libreplanet.org/u/libreplanet/m/securely-backing-up-gpg-private-keys-to-the-cloud/)
   - [[slides|keysafe-libreplanet.pdf]]
+
+## DebConf 17, Montreal, Canada
+
+* "Life After Debian"
+  - August 10th, 3:30 pm
+  - [abstract](https://debconf17.debconf.org/talks/21/)