Adjust English idiom and clarify directions (chapters 4.5 and 4.6).

2 files changed, 17 insertions, 17 deletions

diff --git a/chapter04/aboutsbus.xml b/chapter04/aboutsbus.xml
index 1928423ea..82934d851 100644
--- a/chapter04/aboutsbus.xml
+++ b/chapter04/aboutsbus.xml
@@ -13,25 +13,25 @@
   <para>Many people would like to know beforehand approximately how long
   it takes to compile and install each package. Because Linux From
   Scratch can be built on many different systems, it is impossible to
-  provide accurate time estimates. The biggest package (Glibc) will
+  provide absolute time estimates. The biggest package (Glibc) will
   take approximately 20 minutes on the fastest systems, but could take
   up to three days on slower systems! Instead of providing actual times,
   the Standard Build Unit (SBU) measure will be
   used instead.</para>
 
   <para>The SBU measure works as follows. The first package to be compiled
-  from this book is binutils in <xref linkend="chapter-cross-tools"/>. The
-  time it takes to compile this package is what will be referred to as the
-  Standard Build Unit or SBU. All other compile times will be expressed relative
-  to this time.</para>
+  is binutils in <xref linkend="chapter-cross-tools"/>. The
+  time it takes to compile this package is what we will refer to as the
+  Standard Build Unit or SBU. All other compile times will be expressed in
+  terms of this unit of time.</para>
 
   <para>For example, consider a package whose compilation time is 4.5
-  SBUs. This means that if a system took 10 minutes to compile and
+  SBUs. This means that if your system took 10 minutes to compile and
   install the first pass of binutils, it will take
-  <emphasis>approximately</emphasis> 45 minutes to build this example package.
-  Fortunately, most build times are shorter than the one for binutils.</para>
+  <emphasis>approximately</emphasis> 45 minutes to build the example package.
+  Fortunately, most build times are shorter than one SBU.</para>
 
-  <para>In general, SBUs are not entirely accurate because they depend on many
+  <para>SBUs are not entirely accurate because they depend on many
   factors, including the host system's version of GCC.  They are provided here
   to give an estimate of how long it might take to install a package, but the
   numbers can vary by as much as dozens of minutes in some cases.</para>
@@ -45,15 +45,15 @@
 
     <screen role="nodump"><userinput>export MAKEFLAGS='-j4'</userinput></screen>
 
-    <para>or just building with:</para>
+    <para>or by building with:</para>
 
     <screen role="nodump"><userinput>make -j4</userinput></screen>
 
     <para>When multiple processors are used in this way, the SBU units in the
     book will vary even more than they normally would.  In some cases, the make
     step will simply fail.  Analyzing the output of the build process will also
-    be more difficult because the lines of different processes will be
-    interleaved.  If you run into a problem with a build step, revert back to a
+    be more difficult because the lines from different processes will be
+    interleaved.  If you run into a problem with a build step, revert to a
     single processor build to properly analyze the error messages.</para>
   </note>
 
diff --git a/chapter04/abouttestsuites.xml b/chapter04/abouttestsuites.xml
index 9206f33be..459472be0 100644
--- a/chapter04/abouttestsuites.xml
+++ b/chapter04/abouttestsuites.xml
@@ -27,21 +27,21 @@
   <note>
     <para>Running the test suites in <xref linkend="chapter-cross-tools"/>
     and <xref linkend="chapter-temporary-tools"/>
-    is impossible, since the programs are compiled with a cross-compiler,
-    so are not supposed to be able to run on the build host.</para>
+    is pointless; since the test programs are compiled with a cross-compiler,
+    they probably can't run on the build host.</para>
   </note>
 
   <para>A common issue with running the test suites for binutils and GCC
-  is running out of pseudo terminals (PTYs). This can result in a high
+  is running out of pseudo terminals (PTYs). This can result in a large
   number of failing tests. This may happen for several reasons, but the
   most likely cause is that the host system does not have the
   <systemitem class="filesystem">devpts</systemitem> file system set up
   correctly. This issue is discussed in greater detail at
   <ulink url="&lfs-root;lfs/faq.html#no-ptys"/>.</para>
 
-  <para>Sometimes package test suites will fail, but for reasons which the
+  <para>Sometimes package test suites will fail for reasons which the
   developers are aware of and have deemed non-critical. Consult the logs located
   at <ulink url="&test-results;"/> to verify whether or not these failures are
-  expected. This site is valid for all tests throughout this book.</para>
+  expected. This site is valid for all test suites throughout this book.</para>
 
 </sect1>