diff --git a/part3intro/toolchaintechnotes.xml b/part3intro/toolchaintechnotes.xml
index 7401350d8..f044322e6 100644
--- a/part3intro/toolchaintechnotes.xml
+++ b/part3intro/toolchaintechnotes.xml
@@ -201,7 +201,7 @@
     is slightly adjusted by changing the "vendor" field in the
     <envar>LFS_TGT</envar> variable so it says &quot;lfs&quot;. We also use the
     <parameter>--with-sysroot</parameter> option when building the cross-linker and
-    cross-compiler to tell them where to find the needed host files. This
+    cross-compiler, to tell them where to find the needed host files. This
     ensures that none of the other programs built in <xref
     linkend="chapter-temporary-tools"/> can link to libraries on the build
     machine. Only two stages are mandatory, plus one more for tests.</para>
@@ -238,8 +238,8 @@
     on a machine using the already installed distribution. <quote>On
     lfs</quote> means the commands are run in a chrooted environment.</para>
 
-    <para>Now, there is more about cross-compiling: the C language is not
-    just a compiler, but also defines a standard library. In this book, the
+    <para>This is not yet the end of the story. The C language is not
+    merely a compiler; it also defines a standard library. In this book, the
     GNU C library, named glibc, is used (there is an alternative, &quot;musl&quot;). This library must
     be compiled for the LFS machine; that is, using the cross-compiler cc1.
     But the compiler itself uses an internal library providing complex
@@ -256,22 +256,22 @@
     <para>The upshot of the preceding paragraph is that cc1 is unable to
     build a fully functional libstdc++ with the degraded libgcc, but cc1
     is the only compiler available for building the C/C++ libraries
-    during stage 2. Of course, the compiler built by stage 2, cc-lfs,
-    would be able to build those libraries, but:</para>
+    during stage 2. There are two reasons we don't immediately use the
+    compiler built in stage 2, cc-lfs, to build those libraries.</para>
 
     <itemizedlist>
       <listitem>
         <para>
-          Generally cc-lfs cannot run on pc (the host distro).  Despite the
-          triplets of pc and lfs are compatible to each other, an executable
-          for lfs will depend on glibc-&glibc-version; while the host distro
-          may utilize a different libc implementation (for example, musl) or
+          Generally speaking, cc-lfs cannot run on pc (the host system).  Even though the
+          triplets for pc and lfs are compatible with each other, an executable
+          for lfs must depend on glibc-&glibc-version;; the host distro
+          may utilize either a different implementation of libc (for example, musl), or
           a previous release of glibc (for example, glibc-2.13).
         </para>
       </listitem>
       <listitem>
         <para>
-          Even if cc-lfs happens to run on pc, using it on pc would create
+          Even if cc-lfs can run on pc, using it on pc would create
           a risk of linking to the pc libraries, since cc-lfs is a native
           compiler.
         </para>
@@ -279,16 +279,16 @@
     </itemizedlist>
 
     <para>So when we build gcc stage 2, we instruct the building system to
-    rebuild libgcc and libstdc++ with cc1, but link libstdc++ to the newly
-    rebuilt libgcc instead of the degraded build.  Then the rebuilt
-    libstdc++ will be fully functional.</para>
+    rebuild libgcc and libstdc++ with cc1, but we link libstdc++ to the newly
+    rebuilt libgcc instead of the old, degraded build.  This makes the rebuilt
+    libstdc++ fully functional.</para>
 
     <para>In &ch-final; (or <quote>stage 3</quote>), all the packages needed for
     the LFS system are built. Even if a package has already been installed into
     the LFS system in a previous chapter, we still rebuild the package.  The main reason for
-    rebuilding these packages is to make them stable: if we reinstall a LFS
-    package on a complete LFS system, the installed content of the package
-    should be the same as the content of the same package when installed in
+    rebuilding these packages is to make them stable: if we reinstall an LFS
+    package on a completed LFS system, the reinstalled content of the package
+    should be the same as the content of the same package when first installed in
     &ch-final;.  The temporary packages installed in &ch-tmp-cross; or
     &ch-tmp-chroot; cannot satisfy this requirement, because some of them
     are built without optional dependencies, and autoconf cannot