Add a little bit to the conclusion

2023-02-26-binplz.md

@@ -87,7 +87,8 @@ at least once, since the Nixpkgs Hydra doesn't build and cache most things from
 
     The big problem with this is that we would need to come up with some way to
     limit having to pay too much money.  There are a bunch of trade-offs we
-    could consider here, like limiting the number parallel builds, limiting multiple
+    could consider here, like limiting the number parallel builds, making sure the
+    same derivation isn't built multiple times in parallel, limiting multiple
     builds from individual users, limiting our total build time each month, etc.
 
 2.  **Where do we store the build outputs?**
@@ -97,14 +98,15 @@ at least once, since the Nixpkgs Hydra doesn't build and cache most things from
 
     For instance, if we allow users to build binaries from any arbitrary
     Nixpkgs commit, our stores could blow up to tens or hundreds of terrabytes.
-    Or, what if there happens to be some sort of dynamic attr path in Nixpkgs a
-    user could use to keep building different derivations?
+    Or, even if we only allow users to build binaries from a single Nixpkgs
+    commit, what if there happens to be some sort of dynamic attr path in
+    Nixpkgs a user could use to keep building different derivations?
 
     Another problem is that if we're using a builder we don't control (like
     nixbuild.net), we need to get the binary that has just been built from the
-    builder machine to one of our own servers in order to send it down to the
-    user.  But this brings up questions like how to cache binaries, whether
-    to use the normal Nix protocols for fetching derivations, when and where to
+    builder machine to one of our own servers (in order to send it back to the
+    user).  But this brings up questions like how to cache binaries, whether or not
+    to use the normal Nix protocols for fetching derivation outputs, when and where to
     run garbage collection so our web servers don't fill up, etc.
 
 3.  **When, where, and what do we cache?**
@@ -137,14 +139,19 @@ If you're interested in more discussions on each of these problems, check out th
 Other stuff in our lives came up, and we eventually lost steam on binplz.  We were
 never able to make a fully production-ready service.
 
-## Still a Good Idea
+## Conclusion
+
+binplz turned out to be one of those projects where coming up with a
+proof-of-concept is relatively easy, but making it into a production-ready
+service was quite a challenge.
 
 I still think a service like binplz is a neat idea.  It would really show off
 the flexibility and power of Nix and Nixpkgs.  It could be a useful service if
 you need a certain binary in a pinch.  There are a bunch of different directions
 you could take it in to do other cool things.
 
-I hope someone decides to pick up this idea and drive it to completion!
+I hope someone decides to pick up this idea and drive it to completion!  We would be
+very interested to see how you decide to tackle the above problems.
 
 ## Footnotes