2 files changed, 31 insertions, 0 deletions
diff --git a/chapter02/aboutsbus.xml b/chapter02/aboutsbus.xml
new file mode 100644
index 000000000..d78e6b719
--- /dev/null
+++ b/chapter02/aboutsbus.xml
@@ -0,0 +1,30 @@
+<sect1 id="ch02-aboutsbus">
+<title>About SBUs</title>
+<?dbhtml filename="aboutsbus.html" dir="chapter02"?>
+
+<para>SBUs are <emphasis>Static Bash Units</emphasis> and they are our way
+of identifying how long a package takes to compile. Why don't we use normal
+times like anybody else?</para>
+
+<para>The biggest problem is that times cannot be acurate, not even a
+little bit. So many people install LFS on so many different systems, the
+times it takes to compile something varies too much. One package may take
+20 minutes on one system, but that same packages may take 3 days on another
+(this is not an exaggeration). So instead we've come up with a
+<emphasis>Static Bash Unit</emphasis> or <emphasis>SBU</emphasis>.</para>
+
+<para>It works like this: the very first package you compile in this book
+is Bash in chapter 5 and it'll be statically linked. The time it takes to
+compile this package will be the basis and called the SBU. All other
+compile times are relative to the time it takes to install Bash. For
+example, GCC-3.2 takes about 9.5 SBUs and it's proven that this number if
+fairly consistent among a lot of different systems. So multiply 9.5 by the
+number of seconds it takes for Bash to install (the SBU value) and you get
+a close approximation of how long GCC will take on your system.</para>
+
+<para>Note: SBUs don't work on SMP machines. We've seen that SBUs don't
+work well on SMP based machines. So all bets are off if you're lucky enough
+to have an SMP setup.</para>
+
+</sect1>
+
diff --git a/chapter02/chapter02.xml b/chapter02/chapter02.xml
index 56d23ef78..f47d287c2 100644
--- a/chapter02/chapter02.xml
+++ b/chapter02/chapter02.xml
@@ -3,6 +3,7 @@
 <?dbhtml filename="chapter02.html" dir="chapter02"?>
 
 &c2-aboutlfs;
+&c2-aboutsbus;
 &c2-download;
 &c2-install;
 &c2-platform;