diff --git a/Deconstructing_Linux_udev_Rules.rst b/Deconstructing_Linux_udev_Rules.rst
index b3b5494..5e606d9 100644
--- a/Deconstructing_Linux_udev_Rules.rst
+++ b/Deconstructing_Linux_udev_Rules.rst
@@ -93,8 +93,8 @@
 rules will be the first ones read.
 
 
-How Does ``udev`` Read Rules
-============================
+How Does ``udev`` Read Rules?
+=============================
 
 When ``udev`` first starts, or any time it is informed that rules have
 been changed, it first reads a set of system-wide default rules in
@@ -154,11 +154,11 @@
 the thing that was previously matched*.  But, you're not restricted to
 this.  It's entirely possible to write a rule that operates on
 something completely unrelated to the matched condition.  For
-instance, you could write a rule that says, *reboot the computer
-every time my little brother plugs in his favorite thumbdrive*.  This
-is, however, considered Very Bad Manners and may get you sent to your
-room without dinner.  You may, however, have a career developing
-websites for the US government healthcare initiatives.
+instance, you could write a rule that says, *reboot the computer every
+time my little brother plugs in his favorite thumbdrive*.  This is,
+however, considered Very Bad Manners and may get you sent to your room
+without dinner.  You may, however, have a career developing websites
+for US government healthcare initiatives.
 
 Let's take each rule apart, one key-value pair at a time:
 
@@ -235,7 +235,7 @@
 same device will get the same major/minor device numbers every time.
 These numbers are generated by the kernel and are based on the order
 of driver/device loading, the next free number available to the
-kernel, and the cosmic ray count in Goscratchistan.  Only the
+kernel, and the cosmic ray count in Lower Goscratchistan.  Only the
 ``wwid`` (or an equivalent ``UUID``) is guaranteed to be unique, so
 that's what we used here.
 
@@ -260,7 +260,7 @@
     an application.  We don't have to know where the disk is mounted.
     We just have to always refer to ``/dev/my_fine_disk01`` and let
     all this ``udev`` magic do the hard stuff.  Remember, it's our job
-    as Snotty Systems Engineers (sm) to relieve Applications Programmers of
+    as Snotty Systems Engineers (tm) to relieve Applications Programmers of
     as much thinking as possible.  Really, it is.  Look it up in the
     job description.
    
@@ -336,7 +336,11 @@
     "But why", you may ask, "are you using the ``RUN==`` construct?
     Isn't that what ``PROGRAM==`` does?"  Not exactly, Grasshopper.
     ``PROGRAM==`` *always* runs regardless of prior matching.
-    ``RUN==`` *only* runs if all prior matching has been successful.
+    That's because ``PROGRAM==`` is itself a *matching* key-value
+    construct.  It's used to *figure out* whether a match has
+    taken place.  It this has to run every time.   ``RUN==``,
+    on the other hand,  *only* runs if all prior matching has
+    been successful.
 
     Why is that important here?  Say we boot the system, and the
     kernel discovers drives ``/dev/sdh, /dev/sdi,`` and ``/dev/sdj``
@@ -371,9 +375,9 @@
     The DBAs can then configure their database engines to look for the
     symlink name and never worry about what the underlying node
     mapping is for the raw device.  Just as with Applications
-    Programmers, we Snotty Systems Engineers (sm) are required - by law -
-    to make things as easy as possible for DBAs.  Again, you are
-    referred to the job description.
+    Programmers, we Snotty Systems Engineers (tm) are required - by
+    law - to make things as easy as possible for DBAs.  This one isn't
+    actually in the job description, it's just an act of kindness.
 
 
   - ``OWNER:="3009", GROUP:="421", MODE:="0600``
@@ -454,7 +458,7 @@
 Document Revision Information
 =============================
 
-``$Id: Deconstructing_Linux_udev_Rules.rst,v 1.114 2013/11/01 03:00:13 tundra Exp $``
+``$Id: Deconstructing_Linux_udev_Rules.rst,v 1.115 2013/11/01 03:21:43 tundra Exp $``
 
 You can find the latest version of this document at: