diff --git a/Divorce-Your-Linux-Admin.rst b/Divorce-Your-Linux-Admin.rst
index df78f23..33fd09d 100644
--- a/Divorce-Your-Linux-Admin.rst
+++ b/Divorce-Your-Linux-Admin.rst
@@ -176,8 +176,7 @@
      source packages hardwiring of paths. For example, you *have* to
      have the OS copy of ``perl`` installed on your build machine.
      Many open source packages just *insist* that ``perl`` is always
-     to be found under ``/usr/bin``.  Other such system tool
-     dependencies are listed below.
+     to be found under ``/usr/bin``.
 
   4) When you're all done installing and configuring your
      ``linuxbrew`` environment, you just ``tar`` it off somewhere
@@ -286,7 +285,13 @@
 
     4) Now, bootstrap the environment using the native OS compiler tools::
 
-           brew install gcc make
+           brew install gcc make nload
+
+       ``nload``?  Really?  Yes.  Some packages seem to insist that they
+       only way they'll build is via the system tools.  Stuff that depends
+       on ``autoconft``, ``automake``, and ``perl`` can be particularly
+       snarky about this.  So ... we just add such packages to the bootstrap
+       phase.
 
     5) Tidy up::
 
@@ -330,7 +335,7 @@
            ln -s /opt/TundraWare/tools/bin/python2 /opt/TundraWare/tools/bin/python
            ln -s /opt/TundraWare/tools/bin/pip2 /opt/TundraWare/tools/bin/pip
            pip install ansible pew pew[pythonz] -U --ignore-installed
-           brew install emacs file-formula git htop joe nload nmap screen the_silver_searcher tree vim
+           brew install emacs file-formula git htop joe nmap screen the_silver_searcher tree vim
            ... and so on.
 
      5) Save the results::
@@ -351,8 +356,8 @@
 that should be it.
 
 If you also want to be able to install additional packages in the new
-tools instance, you'll need to install system ``perl``, ``automake``,
-etc. as described in the prior section.
+tools instance, you may need to install system ``perl``, ``automake``,
+etc. as mentioned above.
 
 This is not really a great idea, though.  The better way is to keep a
 master tools configuration on a build server, and add- or delete
@@ -373,10 +378,12 @@
     process, for example.
 
   - When you bootstrap the system, you are building it with the OS'
-    own compilers and header files.  If you later copy your work
-    to a machine with a wildly different older-, or new kernel you
-    may run into compatibility issues.  The fix is to redo the above
-    on a host with the kernel version of interest.
+    own compilers and header files.  You're actually producing a
+    compiler that will be used to compile the rest of your packages.
+    If you later copy your work to a machine with a wildly different
+    older- or newer kernel, you may run into compatibility issues.
+    The fix is to redo the above on a host with the kernel version of
+    interest.
 
 
 Resources
@@ -397,7 +404,7 @@
 
 If you run into a problem building a package, run this command::
 
-     brew gist-log package-name
+     brew gist-logs package-name
 
 This produces a Github gist URL you can submit to the devs for help.