Recent changes to this wiki:

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/)

foo
diff --git a/devblog/disk_partitioning_nitty_gritty.mdwn b/devblog/disk_partitioning_nitty_gritty.mdwn
new file mode 100644
index 0000000..6150ecc
--- /dev/null
+++ b/devblog/disk_partitioning_nitty_gritty.mdwn
@@ -0,0 +1,30 @@
+The secret-project can probably partition disks now. I have not tried it
+yet.
+
+I generalized propellor's PartSpec DSL, which had been used for only
+auto-fitting disk images to chroot sizes, to also support things like
+partitions that use some percentage of the disk.
+
+A sample partition table using that, that gives `/` and `/srv` each 20% of
+the disk, has a couple of fixed size partitions, and uses the rest for `/home`:
+
+	[ partition EXT2 `mountedAt` "/boot"
+		`setFlag` BootFlag
+		`setSize` MegaBytes 512
+	, partition EXT4 `mountedAt` "/"
+		`useDiskSpace` (Percent 20)
+	, partition EXT4 `mountedAt` "/srv"
+		`useDiskSpace` (Percent 20)
+	, partition EXT4 `mountedAt` "/home"
+		`useDiskSpace` RemainingSpace
+	, swapPartition (MegaBytes 1024)
+        ]
+
+It would probably be good to extend that with a combinator that sets
+a minimum allows size, so eg `/` can be made no smaller than 4 GB.
+The implementation should make it simple enough to add such combinators.
+
+I thought about reusing the disk image auto-fitting code, so the 
+target's `/` would start at the size of the installer's `/`.
+May yet do that; it would make some sense when the target and
+installer are fairly similar systems.

devblog
diff --git a/devblog/a_plan_comes_together.mdwn b/devblog/a_plan_comes_together.mdwn
new file mode 100644
index 0000000..1ba7621
--- /dev/null
+++ b/devblog/a_plan_comes_together.mdwn
@@ -0,0 +1,10 @@
+After building the neato Host versioning described in
+[[blog/entry/Functional_Reactive_Propellor]] this weekend,
+I was able to clean up secret-project's config file significantly
+It's feeling close to the final version now.
+
+At this point, the disk image it builds is almost capable of installing the
+target system, and will try to do so when the user tells it to. But,
+choosing and partitioning of the target system disk is not implemented yet,
+so it installs to a chroot which will fail due to lack of disk space there.
+So, I have not actually tested it yet.

correct spelling mistakes
diff --git a/blog/entry/Functional_Reactive_Propellor.mdwn b/blog/entry/Functional_Reactive_Propellor.mdwn
index 40abb13..2f491f7 100644
--- a/blog/entry/Functional_Reactive_Propellor.mdwn
+++ b/blog/entry/Functional_Reactive_Propellor.mdwn
@@ -18,7 +18,7 @@ I wrote this code, and it made me super happy!
 		      )
 		& ver (   (== Installer) --> autostartInstaller )
 
-This is doing so much in so little space and with so luttle fuss! It's
+This is doing so much in so little space and with so little fuss! It's
 completely defining two different versions of a `Host`. One version is the
 `Installer`, which in turn installs the `Target`. The code above provides
 all the information that [[code/propellor]] needs to  *convert* a copy of
@@ -42,7 +42,7 @@ out of git. But then I ran into the situation where I needed these two
 closely related hosts to be defined in a single file, and it all fell
 into place.
 
-The basic idea is that propellor first reverts all the revertable
+The basic idea is that propellor first reverts all the revertible
 properties for other versions. Then it ensures the property for the current
 version.
 

link
diff --git a/blog/entry/Functional_Reactive_Propellor.mdwn b/blog/entry/Functional_Reactive_Propellor.mdwn
index bb04fc3..40abb13 100644
--- a/blog/entry/Functional_Reactive_Propellor.mdwn
+++ b/blog/entry/Functional_Reactive_Propellor.mdwn
@@ -72,6 +72,8 @@ Notice that I've embedded a small DSL for versioning into the propellor
 config file syntax. While implementing versioning took all day,
 that part was super easy; Haskell config files win again!
 
+[API documentation for this feature](http://hackage.haskell.org/package/propellor/docs/Propellor-Property-Versioned.html)
+
 PS: Not really FRP, probably. But time-varying in a FRP-like way.
 
 ---

foo
diff --git a/blog/entry/I_am_ArchiveTeam.mdwn b/blog/entry/I_am_ArchiveTeam.mdwn
index 0476af8..a76dae0 100644
--- a/blog/entry/I_am_ArchiveTeam.mdwn
+++ b/blog/entry/I_am_ArchiveTeam.mdwn
@@ -12,7 +12,7 @@ It's even been the subject of
 [serious academic study as outlined in this talk](http://cdn.media.ccc.de/congress/2014/h264-hd/31c3-6373-en-de-The_Only_Thing_We_Know_About_Cyberspace_Is_That_Its_640x480_hd.mp4),
 which is pretty awesome.
 
-<img src="https://pbs.twimg.com/media/CAMZihSVAAEHyAa.jpg:small" alt="Jason Scott in full stage regalia">
+[[pics/sketchcow.jpeg]]
 
 I'm happy to let this guy be the public face of ArchiveTeam in
 internet meme-land. It's a 0.1% project for me, and has grown into a
diff --git a/blog/pics/sketchcow.jpeg b/blog/pics/sketchcow.jpeg
new file mode 100644
index 0000000..e625112
Binary files /dev/null and b/blog/pics/sketchcow.jpeg differ

blog
diff --git a/blog/entry/Functional_Reactive_Propellor.mdwn b/blog/entry/Functional_Reactive_Propellor.mdwn
new file mode 100644
index 0000000..bb04fc3
--- /dev/null
+++ b/blog/entry/Functional_Reactive_Propellor.mdwn
@@ -0,0 +1,82 @@
+I wrote this code, and it made me super happy!
+
+	data Variety = Installer | Target
+		deriving (Eq)
+
+	seed :: UserInput -> Versioned Variety Host
+	seed userinput ver = host "foo"
+		& ver (   (== Installer) --> hostname "installer"
+		      <|> (== Target)    --> hostname (inputHostname userinput)
+		      )
+		& osDebian Unstable X86_64
+		& Apt.stdSourcesList
+		& Apt.installed ["linux-image-amd64"]
+		& Grub.installed PC
+		& XFCE.installed
+		& ver (   (== Installer) --> desktopUser defaultUser
+		      <|> (== Target)    --> desktopUser (inputUsername userinput)
+		      )
+		& ver (   (== Installer) --> autostartInstaller )
+
+This is doing so much in so little space and with so luttle fuss! It's
+completely defining two different versions of a `Host`. One version is the
+`Installer`, which in turn installs the `Target`. The code above provides
+all the information that [[code/propellor]] needs to  *convert* a copy of
+the `Installer` into the `Target`, which it can do very efficiently. For
+example, it knows that the default user account should be deleted, and a
+new user account created based on the user's input of their name.
+
+The germ of this idea comes from a short presentation I made about
+propellor in Portland several years ago. I was describing
+`RevertableProperty`, and Joachim Breitner pointed out that to use it, the
+user essentially has to keep track of the evolution of their `Host` in
+their head. It would be better for propellor to know what past versions
+looked like, so it can know when a `RevertableProperty` needs to be
+reverted.
+
+I didn't see a way to address the objection for years. I was hung up
+on the problem that propellor's properties can't be compared for equality,
+because functions can't be compared for equality (generally). And on the
+problem that it would be hard for propellor to pull old versions of a `Host`
+out of git. But then I ran into the situation where I needed these two
+closely related hosts to be defined in a single file, and it all fell
+into place.
+
+The basic idea is that propellor first reverts all the revertable
+properties for other versions. Then it ensures the property for the current
+version.
+
+Another use for it would be if you wanted to be able to roll back changes
+to a Host. For example:
+
+	foos :: Versioned Int Host
+	foos ver = host "foo"
+		& hostname "foo.example.com"
+		& ver (   (== 1) --> Apache.modEnabled "mpm_worker"
+		      <|> (>= 2) --> Apache.modEnabled "mpm_event"
+		      )
+		& ver ( (>= 3)   --> Apt.unattendedUpgrades )
+
+	foo :: Host
+	foo = foos `version` (4 :: Int)
+
+Versioned properties can also be defined:
+
+	foobar :: Versioned Int -> RevertableProperty DebianLike DebianLike
+	foobar ver =
+		ver (   (== 1) --> (Apt.installed "foo" <!> Apt.removed "foo")
+		    <|> (== 2) --> (Apt.installed "bar" <!> Apt.removed "bar")
+		    )
+
+Notice that I've embedded a small DSL for versioning into the propellor
+config file syntax. While implementing versioning took all day,
+that part was super easy; Haskell config files win again!
+
+PS: Not really FRP, probably. But time-varying in a FRP-like way.
+
+---
+
+Development of this was sponsored by Jake Vosloo on
+[Patreon](https://patreon.com/joeyh/).
+
+[[!tag propellor]]

typo
diff --git a/devblog/yak_attack.mdwn b/devblog/yak_attack.mdwn
index 1458313..62ddb9f 100644
--- a/devblog/yak_attack.mdwn
+++ b/devblog/yak_attack.mdwn
@@ -8,7 +8,7 @@ another approach, but finally gave in, and taught propellor how to build
 itself with stack. There was an open todo about that, with a hacky
 implementation by Arnaud Bailly, which I cleaned up.
 
-Then the yak shaving continued as I revisited a tricky intermittend
+Then the yak shaving continued as I revisited a tricky intermittent
 propellor bug. Think I've finally squashed that.
 
 Finally, got back to where I left off last week, and at last here's a

devblog
diff --git a/devblog/yak_attack.mdwn b/devblog/yak_attack.mdwn
new file mode 100644
index 0000000..1458313
--- /dev/null
+++ b/devblog/yak_attack.mdwn
@@ -0,0 +1,26 @@
+Integrating propellor and secret-project stalled out last week.
+The problem was that secret-project can only be built with stack right now
+(until my patch to threepenny-gui to fix drag and drop handling gets
+accepted), but propellor did not support building itself with stack.
+
+I didn't want to get sucked into yak shaving on that, and tried to find
+another approach, but finally gave in, and taught propellor how to build
+itself with stack. There was an open todo about that, with a hacky
+implementation by Arnaud Bailly, which I cleaned up.
+
+Then the yak shaving continued as I revisited a tricky intermittend
+propellor bug. Think I've finally squashed that.
+
+Finally, got back to where I left off last week, and at last here's a
+result! This is a disk image that was built entirely from a propellor
+config file, that contains a working propellor installation, and that
+starts up secret-project on boot.
+
+[[!img aliiiive.png]]
+
+Now to make this secret-project actually do something more than looking
+pretty..
+
+----
+
+Today's work was sponsored by Trenton Cronholm on Patreon.
diff --git a/devblog/yak_attack/aliiiive.png b/devblog/yak_attack/aliiiive.png
new file mode 100644
index 0000000..a40f958
Binary files /dev/null and b/devblog/yak_attack/aliiiive.png differ

update
diff --git a/blog/entry/bonus_project.mdwn b/blog/entry/bonus_project.mdwn
index 893d234..a021d95 100644
--- a/blog/entry/bonus_project.mdwn
+++ b/blog/entry/bonus_project.mdwn
@@ -18,3 +18,6 @@ After finishing all that, it was time to
 while enjoying this.
 
 <video controls width=705 src="https://joeyh.name/blog/pics/river.webm">
+
+(Followed by taking delivery of a dumptruck full of gravel -- 23 tons --
+which it turns out was enough for only half of my driveway..)

fix
diff --git a/blog/entry/bonus_project.mdwn b/blog/entry/bonus_project.mdwn
index 41974aa..893d234 100644
--- a/blog/entry/bonus_project.mdwn
+++ b/blog/entry/bonus_project.mdwn
@@ -17,4 +17,4 @@ After finishing all that, it was time to
 [think about this](https://git-annex.branchable.com/design/exporting_trees_to_special_remotes/)
 while enjoying this.
 
-<video controls width=705 src="https://joeyh.name/blog/pics/blog/pics/river.webm">
+<video controls width=705 src="https://joeyh.name/blog/pics/river.webm">

fix
diff --git a/blog/entry/bonus_project.mdwn b/blog/entry/bonus_project.mdwn
index 915d388..41974aa 100644
--- a/blog/entry/bonus_project.mdwn
+++ b/blog/entry/bonus_project.mdwn
@@ -11,7 +11,7 @@ protect the plywood.
 Bonus bonus project to use up paint. (Argh, now I want to increase the size
 of the overflowing grape arbor. Once you start on this kind of stuff..)
 
-[[!img retainingwall.jpg]]
+[[!img pics/retainingwall.jpg]]
 
 After finishing all that, it was time to
 [think about this](https://git-annex.branchable.com/design/exporting_trees_to_special_remotes/)

fix
diff --git a/blog/entry/bonus_project.mdwn b/blog/entry/bonus_project.mdwn
index 30f8e24..915d388 100644
--- a/blog/entry/bonus_project.mdwn
+++ b/blog/entry/bonus_project.mdwn
@@ -1,7 +1,7 @@
 Little bonus project after the solar upgrade was replacing the battery
 box's rotted roof, down to the cinderblock walls.
 
-[[!img src="pics/batterybox.jpg"]]
+[[!img pics/batterybox.jpg]]
 
 Except for a piece of plywood, used all scrap lumber for this project, and
 also scavenged a great set of hinges from a discarded cabinet. I hope the
@@ -11,7 +11,7 @@ protect the plywood.
 Bonus bonus project to use up paint. (Argh, now I want to increase the size
 of the overflowing grape arbor. Once you start on this kind of stuff..)
 
-[[!img src="retainingwall.jpg"]]
+[[!img retainingwall.jpg]]
 
 After finishing all that, it was time to
 [think about this](https://git-annex.branchable.com/design/exporting_trees_to_special_remotes/)

blog update
diff --git a/blog/entry/bonus_project.mdwn b/blog/entry/bonus_project.mdwn
new file mode 100644
index 0000000..30f8e24
--- /dev/null
+++ b/blog/entry/bonus_project.mdwn
@@ -0,0 +1,20 @@
+Little bonus project after the solar upgrade was replacing the battery
+box's rotted roof, down to the cinderblock walls.
+
+[[!img src="pics/batterybox.jpg"]]
+
+Except for a piece of plywood, used all scrap lumber for this project, and
+also scavenged a great set of hinges from a discarded cabinet. I hope the
+paint on all sides and an inch of shingle overhang will be enough to
+protect the plywood.
+
+Bonus bonus project to use up paint. (Argh, now I want to increase the size
+of the overflowing grape arbor. Once you start on this kind of stuff..)
+
+[[!img src="retainingwall.jpg"]]
+
+After finishing all that, it was time to
+[think about this](https://git-annex.branchable.com/design/exporting_trees_to_special_remotes/)
+while enjoying this.
+
+<video controls width=705 src="https://joeyh.name/blog/pics/blog/pics/river.webm">
diff --git a/blog/pics/batterybox.jpg b/blog/pics/batterybox.jpg
new file mode 100644
index 0000000..ace344e
Binary files /dev/null and b/blog/pics/batterybox.jpg differ
diff --git a/blog/pics/retainingwall.jpg b/blog/pics/retainingwall.jpg
new file mode 100644
index 0000000..680ea26
Binary files /dev/null and b/blog/pics/retainingwall.jpg differ
diff --git a/blog/pics/river.webm b/blog/pics/river.webm
new file mode 100644
index 0000000..6deec43
Binary files /dev/null and b/blog/pics/river.webm differ

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

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

devblog
diff --git a/devblog/mashup.mdwn b/devblog/mashup.mdwn
new file mode 100644
index 0000000..25e7388
--- /dev/null
+++ b/devblog/mashup.mdwn
@@ -0,0 +1,17 @@
+This was a one step forward, one step back kind of day, as I moved the
+working stuff from yesterday out of my personal propellor config file and
+into the secret-project repository, and stumbled over some issues while
+doing so.
+
+But, I had a crucial idea last night. When propellor is used to build an
+installer image, the installer does not need to bootstrap the target system
+from scratch. It can just copy the installer to the target system, and then
+run propellor there, with a configuration that reverts any properties that
+the installer had but the installed system should not. This will be a
+lot faster and avoid duplicate downloads.
+
+That's similar to how d-i's live-installer works, but simpler, since
+with propellor there's a short list of all the properties that the
+installer has, and propellor knows if a property can be reverted or not.
+
+Today's work was sponsored by Riku Voipio.

link to better blog post
diff --git a/devblog/high_bandwidth_propellor_hacking.mdwn b/devblog/high_bandwidth_propellor_hacking.mdwn
index 7732336..9df8bf7 100644
--- a/devblog/high_bandwidth_propellor_hacking.mdwn
+++ b/devblog/high_bandwidth_propellor_hacking.mdwn
@@ -44,7 +44,7 @@ propellor stuff from home all day, for the first time!
 Up until now, all propellor features involving disk images were
 either tested remotely, or developed while I was away from home.
 It's a cloudy, rainy day; the 
-[[solar_upgrade|blog/entry/DIY_solar_upgrade_complete-ish]]
+[[solar_upgrade|blog/entry/DIY_professional_grade_solar_panel_installation]]
 and [[satellite_internet|blog/entry/end_of_an_era]] paid off.
 
 ----

rename
diff --git a/devblog/high_bandwidth_propellor_hacking.mdwn b/devblog/high_bandwidth_propellor_hacking.mdwn
new file mode 100644
index 0000000..7732336
--- /dev/null
+++ b/devblog/high_bandwidth_propellor_hacking.mdwn
@@ -0,0 +1,52 @@
+Doing a bunch of work on propellor this week. Some bug fixes and
+improvements to disk image building. Also some properties involving the
+XFCE desktop environment.
+
+Putting it all together, I have 28 lines of propellor config file that
+generates a disk image that boots to a XFCE desktop and also
+has propellor installed. I wonder where it will go from here? ;-)
+
+[[!format haskell """
+darkstar :: Host
+darkstar = host "darkstar.kitenet.net" $ props
+	...
+        & imageBuilt "/srv/propellor-disk.img"
+                (Chroot.hostChroot demo (Chroot.Debootstrapped mempty))
+                MSDOS (grubBooted PC)
+                [ partition EXT2 `mountedAt` "/boot"
+                        `setFlag` BootFlag
+                , partition EXT4 `mountedAt` "/"
+                        `mountOpt` errorReadonly
+                        `addFreeSpace` MegaBytes 256
+                , swapPartition (MegaBytes 256)
+                ]
+
+demo :: Host
+demo = host "demo" $ props
+        & osDebian Unstable X86_64
+        & Apt.installed ["linux-image-amd64"]
+        & bootstrappedFrom GitRepoOutsideChroot
+        & User.accountFor user
+        & root `User.hasInsecurePassword` "debian"
+        & user `User.hasInsecurePassword` "debian"
+        & XFCE.installedMin
+        & XFCE.networkManager
+        & XFCE.defaultPanelFor user File.OverwriteExisting
+        & LightDM.autoLogin user
+        & Apt.installed ["firefox"]
+  where
+        user = User "user"
+        root = User "root"
+"""]]
+
+Indcidentially, I have power and bandwidth to work on this kind of
+propellor stuff from home all day, for the first time! 
+Up until now, all propellor features involving disk images were
+either tested remotely, or developed while I was away from home.
+It's a cloudy, rainy day; the 
+[[solar_upgrade|blog/entry/DIY_solar_upgrade_complete-ish]]
+and [[satellite_internet|blog/entry/end_of_an_era]] paid off.
+
+----
+
+Today's work was sponsored by Riku Voipio.
diff --git a/devblog/propellor_hacking.mdwn b/devblog/propellor_hacking.mdwn
deleted file mode 100644
index 7732336..0000000
--- a/devblog/propellor_hacking.mdwn
+++ /dev/null
@@ -1,52 +0,0 @@
-Doing a bunch of work on propellor this week. Some bug fixes and
-improvements to disk image building. Also some properties involving the
-XFCE desktop environment.
-
-Putting it all together, I have 28 lines of propellor config file that
-generates a disk image that boots to a XFCE desktop and also
-has propellor installed. I wonder where it will go from here? ;-)
-
-[[!format haskell """
-darkstar :: Host
-darkstar = host "darkstar.kitenet.net" $ props
-	...
-        & imageBuilt "/srv/propellor-disk.img"
-                (Chroot.hostChroot demo (Chroot.Debootstrapped mempty))
-                MSDOS (grubBooted PC)
-                [ partition EXT2 `mountedAt` "/boot"
-                        `setFlag` BootFlag
-                , partition EXT4 `mountedAt` "/"
-                        `mountOpt` errorReadonly
-                        `addFreeSpace` MegaBytes 256
-                , swapPartition (MegaBytes 256)
-                ]
-
-demo :: Host
-demo = host "demo" $ props
-        & osDebian Unstable X86_64
-        & Apt.installed ["linux-image-amd64"]
-        & bootstrappedFrom GitRepoOutsideChroot
-        & User.accountFor user
-        & root `User.hasInsecurePassword` "debian"
-        & user `User.hasInsecurePassword` "debian"
-        & XFCE.installedMin
-        & XFCE.networkManager
-        & XFCE.defaultPanelFor user File.OverwriteExisting
-        & LightDM.autoLogin user
-        & Apt.installed ["firefox"]
-  where
-        user = User "user"
-        root = User "root"
-"""]]
-
-Indcidentially, I have power and bandwidth to work on this kind of
-propellor stuff from home all day, for the first time! 
-Up until now, all propellor features involving disk images were
-either tested remotely, or developed while I was away from home.
-It's a cloudy, rainy day; the 
-[[solar_upgrade|blog/entry/DIY_solar_upgrade_complete-ish]]
-and [[satellite_internet|blog/entry/end_of_an_era]] paid off.
-
-----
-
-Today's work was sponsored by Riku Voipio.

devblog
diff --git a/devblog/propellor_hacking.mdwn b/devblog/propellor_hacking.mdwn
new file mode 100644
index 0000000..7732336
--- /dev/null
+++ b/devblog/propellor_hacking.mdwn
@@ -0,0 +1,52 @@
+Doing a bunch of work on propellor this week. Some bug fixes and
+improvements to disk image building. Also some properties involving the
+XFCE desktop environment.
+
+Putting it all together, I have 28 lines of propellor config file that
+generates a disk image that boots to a XFCE desktop and also
+has propellor installed. I wonder where it will go from here? ;-)
+
+[[!format haskell """
+darkstar :: Host
+darkstar = host "darkstar.kitenet.net" $ props
+	...
+        & imageBuilt "/srv/propellor-disk.img"
+                (Chroot.hostChroot demo (Chroot.Debootstrapped mempty))
+                MSDOS (grubBooted PC)
+                [ partition EXT2 `mountedAt` "/boot"
+                        `setFlag` BootFlag
+                , partition EXT4 `mountedAt` "/"
+                        `mountOpt` errorReadonly
+                        `addFreeSpace` MegaBytes 256
+                , swapPartition (MegaBytes 256)
+                ]
+
+demo :: Host
+demo = host "demo" $ props
+        & osDebian Unstable X86_64
+        & Apt.installed ["linux-image-amd64"]
+        & bootstrappedFrom GitRepoOutsideChroot
+        & User.accountFor user
+        & root `User.hasInsecurePassword` "debian"
+        & user `User.hasInsecurePassword` "debian"
+        & XFCE.installedMin
+        & XFCE.networkManager
+        & XFCE.defaultPanelFor user File.OverwriteExisting
+        & LightDM.autoLogin user
+        & Apt.installed ["firefox"]
+  where
+        user = User "user"
+        root = User "root"
+"""]]
+
+Indcidentially, I have power and bandwidth to work on this kind of
+propellor stuff from home all day, for the first time! 
+Up until now, all propellor features involving disk images were
+either tested remotely, or developed while I was away from home.
+It's a cloudy, rainy day; the 
+[[solar_upgrade|blog/entry/DIY_solar_upgrade_complete-ish]]
+and [[satellite_internet|blog/entry/end_of_an_era]] paid off.
+
+----
+
+Today's work was sponsored by Riku Voipio.

Added a comment: Nice Work
diff --git a/blog/entry/12_to_24_volt_house_conversion/comment_1_0a33f98564ffab61375d25b98e1c28a8._comment b/blog/entry/12_to_24_volt_house_conversion/comment_1_0a33f98564ffab61375d25b98e1c28a8._comment
new file mode 100644
index 0000000..d492332
--- /dev/null
+++ b/blog/entry/12_to_24_volt_house_conversion/comment_1_0a33f98564ffab61375d25b98e1c28a8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="A.Steinel@03364ce01487b6885ca91d9dad3c972f961e61a6"
+ nickname="A.Steinel"
+ avatar="http://cdn.libravatar.org/avatar/762306680c167ef96cb280f4fade89a2"
+ subject="Nice Work"
+ date="2017-06-29T20:18:52Z"
+ content="""
+Hi Joey,
+
+I read your blog for a few month now and it is great to see what you accomplished with your cabin.  Keep expanding and blogging about it.
+
+Greetings from Germany,
+Andreas
+"""]]

format
diff --git a/blog/entry/12_to_24_volt_house_conversion.mdwn b/blog/entry/12_to_24_volt_house_conversion.mdwn
index b0bdfcb..8829a99 100644
--- a/blog/entry/12_to_24_volt_house_conversion.mdwn
+++ b/blog/entry/12_to_24_volt_house_conversion.mdwn
@@ -9,7 +9,7 @@ I did not find a lot of references online for converting a whole house's
 voltage from 12V to 24V.
 
 To prepare, I first checked that all the fuses and breakers were rated for
-> 24 volts. (Actually, > 30 volts because it will be 26 volts or so when
+&gt; 24 volts. (Actually, &gt; 30 volts because it will be 26 volts or so when
 charging.) Also, I checked for any shady wiring, and verified that all the
 wires I could see in the attic and wiring closet were reasonably sized
 (10AWG) and in good shape.

blog update
diff --git a/blog/entry/12_to_24_volt_house_conversion.mdwn b/blog/entry/12_to_24_volt_house_conversion.mdwn
new file mode 100644
index 0000000..b0bdfcb
--- /dev/null
+++ b/blog/entry/12_to_24_volt_house_conversion.mdwn
@@ -0,0 +1,75 @@
+Upgrading my solar panels involved switching the house from 12 volts to 24
+volts. No reasonably priced charge controllers can handle 1 KW of PV at 12
+volts.
+
+There might not be a lot of people who need to do this; entirely 12 volt
+offgrid houses are not super common, and most upgrades these days probably
+involve rooftop microinverters and so would involve a switch from DC to AC.
+I did not find a lot of references online for converting a whole house's
+voltage from 12V to 24V.
+
+To prepare, I first checked that all the fuses and breakers were rated for
+> 24 volts. (Actually, > 30 volts because it will be 26 volts or so when
+charging.) Also, I checked for any shady wiring, and verified that all the
+wires I could see in the attic and wiring closet were reasonably sized
+(10AWG) and in good shape.
+
+Then I:
+
+1. Turned off every light, unplugged every plug, 
+   pulled every fuse and flipped every breaker.
+2. Rewired the battery bank from 12V to 24V.
+3. Connected the battery bank to the new charge controller.
+4. Engaged the main breaker, and waited for anything strange.
+5. Screwed in one fuse at a time.
+
+## lighting
+
+The house used all fluorescent lights, and they have ballasts rated for
+only 12V. While they work at 24V, they might blow out sooner or overheat.
+In fact one died this evening, and while it was flickering before, I
+suspect the 24V did it in. It makes sense to replace them with more
+efficient LED lights anyway. I found some 12-24V DC LED lights for regular
+screw-in (edison) light fixtures. Does not seem very common; Amazon only
+had a few models and they shipped from China.
+
+Also, I ordered a 15 foot long, 300 LED strip light, which runs on 24V DC
+and has an adhesive backing. Great stuff -- it can be cut to different
+lengths and stuck anywhere. I installed some underneath the cook stove hood
+and the kitchen cabinets, which didn't have lights before.
+
+Similar LED strips are used in some desktop lamps. My lamp 
+was 12V only (barely lit at 24V), but I was able to replace its LED
+strip, upgrading it to 24V and three times as bright.
+
+(Christmas lights are another option; many LED christmas lights run on
+24V.)
+
+## appliances
+
+My Lenovo laptop's power supply that I use in the house is a vehicle DC-DC
+converter, and is rated for 12-24V. It seems to be running fine at 26V,
+did not get warm even when charging the laptop up from empty.
+
+I'm using buck converters to run various USB powered 
+(5V) ARM boxes such as my sheevaplug. They're quarter sized, so fit
+anywhere, and are very efficient.
+
+My satellite internet receiver is running with a large buck converter,
+feeding 12V to an inverter, feeding to a 30V DC power supply. That triple
+conversion is inneficient, but it works for now.
+
+The ceiling fan runs on 24V, and does not seem to run much faster than on
+12V. It may be rated for 12-24V. Can't seem to find any info about it.
+
+The radio is a 12V car radio. I used a
+[LM317](https://en.wikipedia.org/wiki/LM317) to run it on 24V, to avoid
+the RF interference a buck converter would have produced. This is a very
+inneficient conversion; half of the power is wasted as heat. But
+since I can stream internet radio all day now via satellite,
+I'll not use the FM radio very often.
+
+Fridge... still running on propane for now, but I have an idea for a way to
+build a cold storage battery that will use excess power from the PV array,
+and keep a fridge at a constant 34 degrees F. Next home improvement project
+in the queue.

blog update
diff --git a/blog/entry/DIY_solar_upgrade_complete-ish.mdwn b/blog/entry/DIY_solar_upgrade_complete-ish.mdwn
new file mode 100644
index 0000000..5ab84cb
--- /dev/null
+++ b/blog/entry/DIY_solar_upgrade_complete-ish.mdwn
@@ -0,0 +1,14 @@
+Success! I received the Tracer4215BN charge controller where UPS
+accidentially-on-purpose delivered it to a neighbor, and got it connected
+up, and the battery bank rewired to 24V in a couple hours.
+
+[[!img pics/solar_upgrade/chargecontroller.jpg alt="charge controller
+reading 66.1V at 3.4 amps on panels, charging battery at 29.0V at 7.6A"]]
+
+Here it's charging the batteries at 220 watts, and that picture was taken
+at 5 pm, when the light hits the panels at nearly a 90 degree angle.
+Compare with the old panels, where the maximum I ever recorded at high noon
+was 90 watts. I've made more power since 4:30 pm than I used to be able to
+make in a day! \o/
+
+[[!tag solar DIY]]
diff --git a/blog/pics/solar_upgrade/chargecontroller.jpg b/blog/pics/solar_upgrade/chargecontroller.jpg
new file mode 100644
index 0000000..3d71d29
Binary files /dev/null and b/blog/pics/solar_upgrade/chargecontroller.jpg differ

Added a comment: How will this change things for you?
diff --git a/blog/entry/PV_array_is_hot/comment_1_682cf477f9b03b898983f6a2db63abdb._comment b/blog/entry/PV_array_is_hot/comment_1_682cf477f9b03b898983f6a2db63abdb._comment
new file mode 100644
index 0000000..965ab36
--- /dev/null
+++ b/blog/entry/PV_array_is_hot/comment_1_682cf477f9b03b898983f6a2db63abdb._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="danny@0634b3dbfcf01f496a662052eda825ecce9a9a5d"
+ nickname="danny"
+ avatar="http://cdn.libravatar.org/avatar/6695befc063187009fce565f64ef88b2"
+ subject="How will this change things for you?"
+ date="2017-06-26T06:46:10Z"
+ content="""
+Congratulations! I'm interested in what all this new power will transform (no pun intended) your work and life habits!
+"""]]

correction
diff --git a/blog/entry/PV_array_is_hot.mdwn b/blog/entry/PV_array_is_hot.mdwn
index e3350b5..65458fb 100644
--- a/blog/entry/PV_array_is_hot.mdwn
+++ b/blog/entry/PV_array_is_hot.mdwn
@@ -7,9 +7,12 @@ than what I'm used to.
 
 [[!img pics/solar_upgrade/combinerwiring.jpg alt="PV combiner box wiring"]]
 
-And the new PV array is hot! This should read close to 112 V at solar noon;
-so for 4 pm, 66.8 V seems reasonable.
+And the new PV array is hot!
 
 [[!img pics/solar_upgrade/pvhot.jpg alt="multimeter reading 66.8 DVC"]]
 
+Update: The panels have an open circuit voltage of 35.89 and are in strings
+of 2, so I'd expect to see 71.78 V with only my multimeter connected. So
+I'm losing 0.07 volts to wiring, which is less than I designed for.
+
 [[!tag DIY solar]]

blog update
diff --git a/blog/entry/PV_array_is_hot.mdwn b/blog/entry/PV_array_is_hot.mdwn
new file mode 100644
index 0000000..e3350b5
--- /dev/null
+++ b/blog/entry/PV_array_is_hot.mdwn
@@ -0,0 +1,15 @@
+Only took a couple hours to wire up and mount the combiner box.
+
+[[!img pics/solar_upgrade/combinerbox.jpg alt="PV combiner box with breakers"]]
+
+Something about larger wiring like this is enjoyable. So much less fiddly
+than what I'm used to.
+
+[[!img pics/solar_upgrade/combinerwiring.jpg alt="PV combiner box wiring"]]
+
+And the new PV array is hot! This should read close to 112 V at solar noon;
+so for 4 pm, 66.8 V seems reasonable.
+
+[[!img pics/solar_upgrade/pvhot.jpg alt="multimeter reading 66.8 DVC"]]
+
+[[!tag DIY solar]]
diff --git a/blog/entry/advogato/advogato_20-2000-04-11-00-00/comment_1_bbd9e146d640f0fc8ac26259ea957c7c._comment b/blog/entry/advogato/advogato_20-2000-04-11-00-00/comment_1_bbd9e146d640f0fc8ac26259ea957c7c._comment
deleted file mode 100644
index 052f316..0000000
--- a/blog/entry/advogato/advogato_20-2000-04-11-00-00/comment_1_bbd9e146d640f0fc8ac26259ea957c7c._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawnF6mfrWFMdvdSEJFcmYpl2sxVJnF0-qbE"
- nickname="Ravi"
- subject="wishom teeth pain"
- date="2011-08-17T18:56:13Z"
- content="""
-wisdom teeth give many problem if it doesnt comes out properly. so it is better to removal of <a href=\"http://ewisdomteethpain.com/\">wisdom teeth</a>. there is a little surgery that will be done with in 2 hours.
-"""]]
diff --git a/blog/pics/solar_upgrade/combinerbox.jpg b/blog/pics/solar_upgrade/combinerbox.jpg
new file mode 100644
index 0000000..295d7d0
Binary files /dev/null and b/blog/pics/solar_upgrade/combinerbox.jpg differ
diff --git a/blog/pics/solar_upgrade/combinerwiring.jpg b/blog/pics/solar_upgrade/combinerwiring.jpg
new file mode 100644
index 0000000..361cc53
Binary files /dev/null and b/blog/pics/solar_upgrade/combinerwiring.jpg differ
diff --git a/blog/pics/solar_upgrade/pvhot.jpg b/blog/pics/solar_upgrade/pvhot.jpg
new file mode 100644
index 0000000..11cba45
Binary files /dev/null and b/blog/pics/solar_upgrade/pvhot.jpg differ

blog update
diff --git a/blog/entry/DIY_professional_grade_solar_panel_installation.mdwn b/blog/entry/DIY_professional_grade_solar_panel_installation.mdwn
new file mode 100644
index 0000000..08494ac
--- /dev/null
+++ b/blog/entry/DIY_professional_grade_solar_panel_installation.mdwn
@@ -0,0 +1,78 @@
+I've installed 1 kilowatt of solar panels on my roof, using professional
+grade eqipment. The four panels are Astronergy 260 watt panels, and they're
+mounted on IronRidge XR100 rails. Did it all myself, without help.
+
+[[!img pics/solar_upgrade/housepanels.jpg alt="house with 4 solar panels on roof"]]
+
+I had three goals for this install:
+
+1. Cheap but sturdy. Total cost will be under $2500. It would probably cost
+   at least twice as much to get a professional install, and the pros might
+   not even want to do such a small install.
+2. Learn the roof mount system. I want to be able to add more panels, remove
+   panels when working on the roof, and understand everything.
+3. Make every day a sunny day. With my current solar panels, I get around
+   10x as much power on a sunny day as a cloudy day, and I have plenty of
+   power on sunny days. So 10x the PV capacity should be a good amount of
+   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
+roof by myself.
+
+I was able to find the rafters, without needing a stud finder, after I
+removed the roof's vent caps, which exposed the rafters. The shingles were
+on straight enough that I could follow the lines down and drilled into the
+rafter on the first try every time. And I got the rails on spaced well and
+straight, although I could have spaced the FlashFeet out better (oops).
+
+My drill ran out of juice half-way, and I had to hack it to recharge on
+solar power, but that's another story. Between the learning curve, a lot of
+careful measurement, not the greatest shoes for roofing, and waiting for
+recharging, it took two days to get the 8 FlashFeet installed and the rails
+mounted.
+
+Taking a break from that and swimming in the river, I realized I should
+have been wearing my water shoes on the roof all along. Super soft and
+nubbly, they make me feel like a gecko up there! After recovering from an
+(unrelated) achilles tendon strain, I got the panels installed today.
+
+Turns out they're not hard to handle on the roof by myself. Getting them up
+a ladder to the roof by yourself would normally be another story, but my
+house has a 2 foot step up from the back retaining wall to the roof, and
+even has a handy grip beam as you step up.
+
+[[!img pics/solar_upgrade/stepup.jpg alt="roof next to the ground with a couple of cinderblock steps"]]
+
+The last gotcha, which I luckily anticipated, is that panels will slide
+down off the rails before you can get them bolted down. This is where a
+second pair of hands would have been most useful. But, I macguyvered a
+solution, attaching temporary clamps before bringing a panel up, that
+stopped it sliding down while I was attaching it.
+
+[[!img pics/solar_upgrade/clamp.jpg alt="clamp temporarily attached to side of panel"]]
+
+I also finished the outside wiring today. Including the one hack of this
+install so far. Since the local hardware store didn't have a suitable
+conduit to bring the cables off the roof, I cobbled one together from pipe,
+with foam inserts to prevent chafing.
+
+[[!img pics/solar_upgrade/conduit.jpg alt="some pipe with 5 wires running
+through it, attached to the side of the roof"]]
+
+While I have 1 kilowatt of power on my roof now, I won't be able to use it
+until next week. After ordering the upgrade, I realized that my old PWM
+charge controller would be able to handle less than half the power, and to
+get even that I would have needed to mount the fuse box near the top of the
+roof and run down a large and expensive low-voltage high-amperage cable,
+around OO AWG size. Instead, I'll be upgrading to a MPPT controller, and
+running a single 150 volt cable to it.
+
+Then, since the MPPT controller can only handle 1 kilowatt when it's
+converting to 24 volts, not 12 volts, I'm gonna have to convert the
+entire house over from 12V DC to 24V DC, including changing all the light
+fixtures and rewiring the battery bank...
+
+[[!img pics/solar_upgrade/panelsside.jpg]]
+
+[[!tag solar diy]]

add
diff --git a/blog/pics/solar_upgrade/clamp.jpg b/blog/pics/solar_upgrade/clamp.jpg
new file mode 100644
index 0000000..c3f98d7
Binary files /dev/null and b/blog/pics/solar_upgrade/clamp.jpg differ
diff --git a/blog/pics/solar_upgrade/conduit.jpg b/blog/pics/solar_upgrade/conduit.jpg
new file mode 100644
index 0000000..04bc14a
Binary files /dev/null and b/blog/pics/solar_upgrade/conduit.jpg differ
diff --git a/blog/pics/solar_upgrade/housepanels.jpg b/blog/pics/solar_upgrade/housepanels.jpg
new file mode 100644
index 0000000..e312525
Binary files /dev/null and b/blog/pics/solar_upgrade/housepanels.jpg differ
diff --git a/blog/pics/solar_upgrade/panelsside.jpg b/blog/pics/solar_upgrade/panelsside.jpg
new file mode 100644
index 0000000..33c7292
Binary files /dev/null and b/blog/pics/solar_upgrade/panelsside.jpg differ
diff --git a/blog/pics/solar_upgrade/stepup.jpg b/blog/pics/solar_upgrade/stepup.jpg
new file mode 100644
index 0000000..99813ce
Binary files /dev/null and b/blog/pics/solar_upgrade/stepup.jpg differ

alt
diff --git a/blog/entry/not_tabletop_solar.mdwn b/blog/entry/not_tabletop_solar.mdwn
index 78e4f04..52890d0 100644
--- a/blog/entry/not_tabletop_solar.mdwn
+++ b/blog/entry/not_tabletop_solar.mdwn
@@ -1,4 +1,4 @@
 Borrowed a pickup truck today to fetch my new solar panels. This is 1
 kilowatt of power on my picnic table.
 
-[[!img pics/solarpanelstable.jpg caption="solar panels on picnic table"]]
+[[!img pics/solarpanelstable.jpg alt="solar panels on picnic table"]]

link
diff --git a/blog/entry/not_tabletop_solar.mdwn b/blog/entry/not_tabletop_solar.mdwn
index 6fae30a..78e4f04 100644
--- a/blog/entry/not_tabletop_solar.mdwn
+++ b/blog/entry/not_tabletop_solar.mdwn
@@ -1,4 +1,4 @@
 Borrowed a pickup truck today to fetch my new solar panels. This is 1
 kilowatt of power on my picnic table.
 
-[[!img solarpanelstable.jpg caption="solar panels on picnic table"]]
+[[!img pics/solarpanelstable.jpg caption="solar panels on picnic table"]]

blog update
diff --git a/blog/entry/not_tabletop_solar.mdwn b/blog/entry/not_tabletop_solar.mdwn
new file mode 100644
index 0000000..6fae30a
--- /dev/null
+++ b/blog/entry/not_tabletop_solar.mdwn
@@ -0,0 +1,4 @@
+Borrowed a pickup truck today to fetch my new solar panels. This is 1
+kilowatt of power on my picnic table.
+
+[[!img solarpanelstable.jpg caption="solar panels on picnic table"]]
diff --git a/blog/pics/solarpanelstable.jpg b/blog/pics/solarpanelstable.jpg
new file mode 100644
index 0000000..e253ee6
Binary files /dev/null and b/blog/pics/solarpanelstable.jpg differ

hmm
diff --git a/devblog/prototype_gamified_interface.mdwn b/devblog/prototype_gamified_interface.mdwn
index a6ec5f7..19d83e2 100644
--- a/devblog/prototype_gamified_interface.mdwn
+++ b/devblog/prototype_gamified_interface.mdwn
@@ -6,9 +6,10 @@ What is this strange thing? It's a prototype, thrown together with
 open clip art in a long weekend. It's an exploration how far an interface
 can diverge from the traditional and still work. And it's a mini-game.
 
-Watch the video, and at the end, try to anwser these questions:
+Watch the video, and at the end, try to answer these questions:
 
-What will you do then? What happens next?
+* What will you do then?
+* What happens next?
 
 Spoilers below...
 

hmm
diff --git a/devblog/prototype_gamified_interface.mdwn b/devblog/prototype_gamified_interface.mdwn
index 71ef759..a6ec5f7 100644
--- a/devblog/prototype_gamified_interface.mdwn
+++ b/devblog/prototype_gamified_interface.mdwn
@@ -6,8 +6,7 @@ What is this strange thing? It's a prototype, thrown together with
 open clip art in a long weekend. It's an exploration how far an interface
 can diverge from the traditional and still work. And it's a mini-game.
 
-As the user interacts with the game, the clutter of objects get knocked off
-the tree, and fall offscreen.
+Watch the video, and at the end, try to anwser these questions:
 
 What will you do then? What happens next?
 

hmm
diff --git a/devblog/prototype_gamified_interface.mdwn b/devblog/prototype_gamified_interface.mdwn
index 8b7d80c..71ef759 100644
--- a/devblog/prototype_gamified_interface.mdwn
+++ b/devblog/prototype_gamified_interface.mdwn
@@ -9,10 +9,12 @@ can diverge from the traditional and still work. And it's a mini-game.
 As the user interacts with the game, the clutter of objects get knocked off
 the tree, and fall offscreen.
 
-What will you do then? What happens next? [[!img middle.png]]
+What will you do then? What happens next?
 
 Spoilers below...
 
+[[!img middle.png]]
+
 What I hope you might have answered to those questions, after watching the
 video, is something like this:
 

hmm
diff --git a/devblog/prototype_gamified_interface.mdwn b/devblog/prototype_gamified_interface.mdwn
index e2e7708..8b7d80c 100644
--- a/devblog/prototype_gamified_interface.mdwn
+++ b/devblog/prototype_gamified_interface.mdwn
@@ -7,18 +7,12 @@ open clip art in a long weekend. It's an exploration how far an interface
 can diverge from the traditional and still work. And it's a mini-game.
 
 As the user interacts with the game, the clutter of objects get knocked off
-the tree, and fall offscreen. Leaving eventually this:
+the tree, and fall offscreen.
 
-[[!img middle.png]]
-
-What will you do then? What happens next?
+What will you do then? What happens next? [[!img middle.png]]
 
 Spoilers below...
 
-<div height=200></div>
-
-[[!img middle.png]]
-
 What I hope you might have answered to those questions, after watching the
 video, is something like this:
 

hmm
diff --git a/devblog/prototype_gamified_interface.mdwn b/devblog/prototype_gamified_interface.mdwn
index 763f6ce..e2e7708 100644
--- a/devblog/prototype_gamified_interface.mdwn
+++ b/devblog/prototype_gamified_interface.mdwn
@@ -9,72 +9,13 @@ can diverge from the traditional and still work. And it's a mini-game.
 As the user interacts with the game, the clutter of objects get knocked off
 the tree, and fall offscreen. Leaving eventually this:
 
+[[!img middle.png]]
+
 What will you do then? What happens next?
 
 Spoilers below...
 
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
-<p>
+<div height=200></div>
 
 [[!img middle.png]]
 

use webm not mp4
diff --git a/devblog/prototype_gamified_interface.mdwn b/devblog/prototype_gamified_interface.mdwn
index 361aae9..763f6ce 100644
--- a/devblog/prototype_gamified_interface.mdwn
+++ b/devblog/prototype_gamified_interface.mdwn
@@ -1,6 +1,6 @@
 And now for something completely different..
 
-<video controls src="https://downloads.kitenet.net/videos/prototype_gamified_interface.mp4" poster="https://joeyh.name/devblog/prototype_gamified_interface/start.png"></video>
+<video controls src="https://downloads.kitenet.net/videos/prototype_gamified_interface.webm" poster="https://joeyh.name/devblog/prototype_gamified_interface/start.png"></video>
 
 What is this strange thing? It's a prototype, thrown together with
 open clip art in a long weekend. It's an exploration how far an interface

devblog
diff --git a/devblog/prototype_gamified_interface.mdwn b/devblog/prototype_gamified_interface.mdwn
new file mode 100644
index 0000000..361aae9
--- /dev/null
+++ b/devblog/prototype_gamified_interface.mdwn
@@ -0,0 +1,139 @@
+And now for something completely different..
+
+<video controls src="https://downloads.kitenet.net/videos/prototype_gamified_interface.mp4" poster="https://joeyh.name/devblog/prototype_gamified_interface/start.png"></video>
+
+What is this strange thing? It's a prototype, thrown together with
+open clip art in a long weekend. It's an exploration how far an interface
+can diverge from the traditional and still work. And it's a mini-game.
+
+As the user interacts with the game, the clutter of objects get knocked off
+the tree, and fall offscreen. Leaving eventually this:
+
+What will you do then? What happens next?
+
+Spoilers below...
+
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+<p>
+
+[[!img middle.png]]
+
+What I hope you might have answered to those questions, after watching the
+video, is something like this:
+
+* What will you do then?  
+  I'll move the egg into the brain-tree.  
+* What happens next?  
+  It will throw away the junk I had installed and replace it with what's in the egg.
+
+The interface I'm diverging from is this kind of thing:
+
+<img src="https://imgs.xkcd.com/comics/permanence.png">
+
+My key design points are these:
+
+* **Avoid words entirely**  
+
+  One of my takeaways from the Debian installer project is that it's
+  important to make the interface support non-English users, but
+  maintaining translations massively slows down development. 
+  I want an interface that can be quickly iterated on or thrown away.
+  
+* **Massively simplify**
+
+  In the Debian installer, we never managed to get rid of as many questions
+  as we wanted to. I'm starting from the other end, and only putting in the
+  absolute most essential questions.
+
+  1. Do you want to delete everything that is on this computer?
+  2. What's the hostname?
+  3. What account to make?
+  4. What password to use?
+  
+  I hope to stop at the first that I've implemented so far. It should be
+  possible to make the hostname easy to change after installation, and for an
+  end user installation, the username doesh't matter much, and the password
+  generally adds little or no security (and desktop environments should make
+  it easy to add a password later).
+
+* **Don't target all the users**
+
+  Trying to target all users constrained the Debian installer in weird ways 
+  while complicating it massively.
+
+  This if not for installing a server or an embedded system.
+  This interface is targeting end users who want a working desktop system 
+  with minimum fuss, and are capable of seeing and dragging.
+  There can be other interfaces for other users.
+
+* **Make it fun**  
+
+  Fun to use, and also fun to develop.
+
+  I'm using [threepenny-gui](http://hackage.haskell.org/package/threepenny-gui)
+  to build the insterface. This lets [Haskell code be written that directly
+  manipulates the web browser's DOM](https://git.joeyh.name/index.cgi/secret-project.git/tree/test.hs).
+  I'm having a lot of fun with that and can already think of other projects
+  I can use threepenny-gui with!
+
+Previously: [[blog/entry/propellor_is_d-i_2.0]]
diff --git a/devblog/prototype_gamified_interface/middle.png b/devblog/prototype_gamified_interface/middle.png
new file mode 100644
index 0000000..359c609
Binary files /dev/null and b/devblog/prototype_gamified_interface/middle.png differ
diff --git a/devblog/prototype_gamified_interface/start.png b/devblog/prototype_gamified_interface/start.png
new file mode 100644
index 0000000..c9802ca
Binary files /dev/null and b/devblog/prototype_gamified_interface/start.png differ

devblog
diff --git a/devblog/debug_me_keyrings.mdwn b/devblog/debug_me_keyrings.mdwn
new file mode 100644
index 0000000..1b9aabc
--- /dev/null
+++ b/devblog/debug_me_keyrings.mdwn
@@ -0,0 +1,19 @@
+Releasing debug-me 1.20170520 today with a major improvement.
+
+Now it will look for the gpg key of the developer in keyring
+files in `/usr/share/debug-me/keyring/`, and tell the user which project(s)
+the developer is known to be a member of. So, for example, Debian
+developers who connect to debug-me sessions of Debian users will be
+identified as a Debian developer. And when I connect to a debug-me user's
+session, debug-me will tell them that I'm the developer of debug-me.
+
+This should help the user decide when to trust a developer to connect to
+their debug-me session. If they develop software that you're using, you
+already necessarily trust them and letting them debug your machine is not 
+a stretch, as long as it's securely logged. 
+
+Thanks to Sean Whitton for the idea of checking the Debian keyring, which
+I've generalized to this.
+
+Also, debug-me is now just an apt-get away for Debian unstable users,
+and I think it may end up in the next Debian release.

format
diff --git a/blog/entry/announcing_debug-me.mdwn b/blog/entry/announcing_debug-me.mdwn
index 6e3dd6b..c982da0 100644
--- a/blog/entry/announcing_debug-me.mdwn
+++ b/blog/entry/announcing_debug-me.mdwn
@@ -1,17 +1,15 @@
 Today I'm excited to release [debug-me](https://debug-me.branchable.com/),
 a program for secure remote debugging.
 
-<blockquote>
-Debugging a problem over email/irc/BTS is slow, tedious, and hard. The developer
-needs to see your problem to understand it. Debug-me aims to make debugging
-fast, fun, and easy, by letting the developer access your computer remotely,
-so they can immediately see and interact with the problem. Making your
-problem their problem gets it fixed fast.
-
-debug-me session is logged and signed with the developer's GnuPG
-key, producing a chain of evidence of what they saw and what they did.
-So the developer's good reputation is leveraged to make debug-me secure.
-</blockquote>
+> Debugging a problem over email/irc/BTS is slow, tedious, and hard. The developer
+> needs to see your problem to understand it. Debug-me aims to make debugging
+> fast, fun, and easy, by letting the developer access your computer remotely,
+> so they can immediately see and interact with the problem. Making your
+> problem their problem gets it fixed fast.
+> 
+> debug-me session is logged and signed with the developer's GnuPG
+> key, producing a chain of evidence of what they saw and what they did.
+> So the developer's good reputation is leveraged to make debug-me secure.
 
 I've recorded a [short screencast demoing debug-me](https://downloads.kitenet.net/videos/debug-me/debug-me-demo.webm).
 

devblog
diff --git a/blog/entry/announcing_debug-me.mdwn b/blog/entry/announcing_debug-me.mdwn
new file mode 100644
index 0000000..6e3dd6b
--- /dev/null
+++ b/blog/entry/announcing_debug-me.mdwn
@@ -0,0 +1,40 @@
+Today I'm excited to release [debug-me](https://debug-me.branchable.com/),
+a program for secure remote debugging.
+
+<blockquote>
+Debugging a problem over email/irc/BTS is slow, tedious, and hard. The developer
+needs to see your problem to understand it. Debug-me aims to make debugging
+fast, fun, and easy, by letting the developer access your computer remotely,
+so they can immediately see and interact with the problem. Making your
+problem their problem gets it fixed fast.
+
+debug-me session is logged and signed with the developer's GnuPG
+key, producing a chain of evidence of what they saw and what they did.
+So the developer's good reputation is leveraged to make debug-me secure.
+</blockquote>
+
+I've recorded a [short screencast demoing debug-me](https://downloads.kitenet.net/videos/debug-me/debug-me-demo.webm).
+
+<video controls width=400 title="debug-me demo" src="https://downloads.kitenet.net/videos/debug-me/debug-me-demo.webm"></video>
+
+And here's a [screencast about debug-me's chain of evidence](https://downloads.kitenet.net/videos/debug-me/debug-me-logs.webm).
+
+<video controls width=400 title="debug-me logs" src="https://downloads.kitenet.net/videos/debug-me/debug-me-logs.webm"></video>
+
+The idea for debug-me came from [[Re:_Debugging_over_email]], and then my
+[Patreon](https://www.patreon.com/joeyh) supporters picked debug-me in a
+poll as a project I should work on. It's been a fun month, designing the
+evidence chain, building a custom efficient protocol with space saving
+hacks, using websockets and protocol buffers and ed25519 for the first
+time, and messing around with low-level tty details. The details of
+debug-me's development are in my [[devblog]].
+
+Anyway, I hope debug-me makes debugging less of a tedious back and forth,
+at least some of the time.
+
+PS: Since debug-me's protocol lets multiple people view the same shell
+session, and optionally interact with it, there could be uses for it beyond
+debugging, including live screencasting, pair programming, etc.
+
+PPS: There needs to be a debug-me server not run by me, so someone
+please [run one](https://debug-me.branchable.com/servers/)..
diff --git a/devblog/debug_me_released.mdwn b/devblog/debug_me_released.mdwn
new file mode 100644
index 0000000..af34c17
--- /dev/null
+++ b/devblog/debug_me_released.mdwn
@@ -0,0 +1,15 @@
+debug-me is released! <https://debug-me.branchable.com/>
+
+I made one last protocol compatability 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.
+
+The release includes a tarball that should let debug-me run on most linux
+systems. I adapted the code from git-annex for
+[[blog/entry/completely_linux_distribution-independent_packaging]]. That
+added 300 lines of code to debug-me's source tree, which is suboptimal. But
+all the options in the Linux app packaging space are suboptimal. Flatpak
+and snappy would both be ok -- if the other one didn't exist and they
+were were installed everywhere. Appimage needs the program to be built against
+an older version of libraries.

devblog
diff --git a/devblog/debug_me_screencast_recording_and_server.mdwn b/devblog/debug_me_screencast_recording_and_server.mdwn
new file mode 100644
index 0000000..3c2d45b
--- /dev/null
+++ b/devblog/debug_me_screencast_recording_and_server.mdwn
@@ -0,0 +1,31 @@
+Recorded a 7 minute screencast demoing debug-me, and another 3 minute
+screencast talking about its log files. That took around 5 hours of work
+actually, between finding a screencast program that works well (I used
+kazam), writing the "script", and setting the scenes for the user and
+developer desktops shown in the screencast.
+
+While recording, I found a bug in debug-me. The gpg key was not available
+when it tried to verify it. I thought that I had seen gpg --verify
+--keyserver download a key from a keyserver and use it to verify but seems
+I was mistaken. So I changed the debug-me protocol to include the gpg
+public key, so it does not need to rely on accessing a keyserver.
+
+Also deployed a debug-me server, <http://debug-me.joeyh.name:8081/>. It's
+not ideal for me to be running the debug-me server, because when me and a
+user are using that server with debug-me, I could use my control of the
+server to prevent the debug-me log being emailed to them, and also delete
+their local copy of the log. 
+
+I have a plan to 
+<https://debug-me.branchable.com/todo/send_to_multiple_servers/>
+that will avoid that problem but it needs a debug-me server run by someone
+else. Perhaps that will happen once I release debug-me; for now the single
+debug-me server will have to do.
+
+Finally, made `debug-me --verify log` check all the signatures and hashes
+in the log file, and display the gpg keys of the participants in the
+debug-me session.
+
+Today's work was sponsored by Jake Vosloo on Patreon.
+
+(Also, Sean Whitton has stepped up to get debug-me into Debian!)