diff --git a/code/blog-static-flake b/code/blog-static-flake
index f2bb36b..67b47d9 160000
--- a/code/blog-static-flake
+++ b/code/blog-static-flake
@@ -1 +1 @@
-Subproject commit f2bb36b862b7c730c42abb0b759ddd3c1c4f3d4b
+Subproject commit 67b47d9c298e7476c2ca211aac5c5fd961637b7b
diff --git a/config-gen.toml b/config-gen.toml
index fe0403c..57e9959 100644
--- a/config-gen.toml
+++ b/config-gen.toml
@@ -4,7 +4,7 @@
       url = "https://dev.danilafe.com/Advent-of-Code/AdventOfCode-2020/src/commit/7a8503c3fe1aa7e624e4d8672aa9b56d24b4ba82"
       path = "aoc-2020"
     [params.submoduleLinks.blogstaticflake]
-      url = "https://dev.danilafe.com/Nix-Configs/blog-static-flake/src/commit/f2bb36b862b7c730c42abb0b759ddd3c1c4f3d4b"
+      url = "https://dev.danilafe.com/Nix-Configs/blog-static-flake/src/commit/67b47d9c298e7476c2ca211aac5c5fd961637b7b"
       path = "blog-static-flake"
     [params.submoduleLinks.serverconfig]
       url = "https://dev.danilafe.com/Nix-Configs/server-config/src/commit/98cffe09546aee1678f7baebdea5eb5fef288935"
diff --git a/content/blog/blog_with_nix.md b/content/blog/blog_with_nix.md
index d2e01af..7006c2a 100644
--- a/content/blog/blog_with_nix.md
+++ b/content/blog/blog_with_nix.md
@@ -116,7 +116,7 @@ Do I really want to specify the `publicPath` each time I want to describe a vers
 What about `settings.replaceUrl`, or the source code? Just like I would in any garden variety language,
 I defined two helper functions:
 
-{{< codelines "Nix" "blog-static-flake/lib.nix" 25 46 >}}
+{{< codelines "Nix" "blog-static-flake/lib.nix" 25 48 >}}
 
 Both of these simply make a call to the `website` function (and thus return derivations), but they
 make some decisions for the caller, and provide a nicer interface by allowing attributes to be omitted.
@@ -255,24 +255,32 @@ which is just `nixpkgs`. The `flake-utils` flake provides some convenient functi
 flakes, and `katex-html` is my own creation, a KaTeX-to-HTML conversion script that I use to post-process the blog.
 
 So what outputs should this flake provide? Well, we've already defined a NixOS module for the blog, and we'd like
-our flake to expose this module to the world. This is the exact purpose of the `outputs.nixosModule` attribute.
-It's sufficient to simply import the module file:
+our flake to expose this module to the world. But the module alone is not enough; its configuration requires a list of
+packages created using our builders. But where does one procure such a list? The caller will need access to the builders
+themselves. To make all of this work, I ended up with the following expression for my `outputs`:
 
-{{< codelines "Nix" "blog-static-flake/flake.nix" 28 28 >}}
+{{< codelines "Nix" "blog-static-flake/flake.nix" 21 34 >}}
 
-This is great, but it's not enough. Specifically, the module configuration requires a list of
-packages created using our builders. But how should the NixOS configuration even reference these builders?
-There's no "standard" way for exposing a pure function from a flake (as far as I know), but the good news is that
-if you add a non-standard attribute to the flake, it will be accessible from wherever it is imported.
-Thus, I simply provide a `buildersFor` function:
+The flake `output` schema provides a standard option for exposing modules, `nixosModule`. Then,
+exposing my `module.nix` file from the flake is simply a matter of importing it, as on line 31.
+There is, however, no standard way for exposing a _function_. The good news is that any
+attribute defined on a flake is accessible from code that imports that flake. Thus, I simply
+added a `buildersFor` function, which, given an operating system, fetches the `nixpkgs` collection
+and LaTeX builder script for that system, and feeds them to the file that defines the `english`
+and `russian` builders. This `buildersFor` function also provides the builders with the two
+different blog sources they reference, `blog-source` and `blog-source-localized`.
 
-{{< codelines "Nix" "blog-static-flake/flake.nix" 23 27 >}}
+The `system` parameter to `buildersFor` is necessary because the set of packages from `nixpkgs` depends on it. Thus, if the
+builders use any packages from the collection (they do), they must know which system to pull packages for.
+This is a common pattern in flakes: the `packages` attribute is typically a system-to-package mapping, too.
 
-The `nixpkgs` flake requires a `system` argument, which means that the builders themselves
-(which depend on packages from `nixpkgs`) need to be aware of what system they're being used for.
-This is why `buildersFor` is itself a function.
+Finally, the last little bit on lines 32 through 34 defines a default package for the flake. This
+is the package that is built if a user runs `nix build .#`. This isn't strictly necessary for my purposes,
+but it's nice to be able to test that the builders still work by running a test build. The
+`eachDefaultSystem` function generates a `defaultPackage` attribute for each of the "default"
+operating systems, so that the package is buildable on more than just my server architecture.
 
-{{< todo >}} This needs to be done {{< /todo >}}
+And that's it for the blog flake! I simply push it to Git, and move on to actually _using_ it from elsewhere.
 
 #### Using the Module