diff --git a/en_US.ISO8859-1/share/sgml/glossary/freebsd-glossary.sgml b/en_US.ISO8859-1/share/sgml/glossary/freebsd-glossary.sgml
index c4ef41788a..90b7cc0ad1 100644
--- a/en_US.ISO8859-1/share/sgml/glossary/freebsd-glossary.sgml
+++ b/en_US.ISO8859-1/share/sgml/glossary/freebsd-glossary.sgml
@@ -1,123 +1,235 @@
 <!-- 
     FreeBSD Specific Glossary Terms
 	Please keep this file sorted.
 
     $FreeBSD$
 -->
 
 <glossary status="draft" id="freebsd-glossary">
   <title>&os; Glossary</title>
   <para>This glossary contains terms and acronyms specific to &os;.</para>
 
   <glossdiv>
     <title>B</title>
 
     <glossentry id="bsd">
       <glossterm>Berkeley Software Distribution</glossterm>
       <acronym>BSD</acronym>
       <glossdef>
 	<para>This is the name that the Computer Systems Research Group
-	  at Berkeley gave to their improvements and modifications to
-	  AT&amp;T's 32V &unix;.</para>
+	  (CSRG) at <ulink url="http://www.berkeley.edu">The University
+	  of California at Berkeley</ulink>
+	  gave to their improvements and modifications to
+	  AT&amp;T's 32V &unix;.
+	  &os; is a descendant of the CSRG work.</para>
       </glossdef>
     </glossentry>
 
     <glossentry id="bikeshed">
       <glossterm>Bikeshed Building</glossterm>
       <glossdef>
 	<para>A phenomenon whereby many people will give an opinion on
 	  an uncomplicated topic, whilst a complex topic receives little
 	  or no discussion.  See the
 	  <ulink url="../faq/misc.html#BIKESHED-PAINTING">FAQ</ulink> for
 	  the origin of the term.</para>
       </glossdef>
     </glossentry>
 
     <glossentry>
       <glossterm>BSD</glossterm>
       <glosssee otherterm="bsd">
     </glossentry>
   </glossdiv>
 
+  <glossdiv>
+    <title>G</title>
+
+    <glossentry id="giant">
+      <glossterm>Giant</glossterm>
+      <glossdef>
+	<para>The name of a mutual exclusion mechanism
+	  (a <literal>sleep mutex</literal>) that protects a large
+	  set of kernel resources.  Although a simple locking mechanism
+	  was adequate in the days where a machine might have only
+	  a few dozen processes, one networking card, and certainly
+	  only one processor, in current times it is an unacceptable
+	  performance bottleneck.  &os; developers are actively working
+	  to replace it with locks that protect individual resources,
+	  which will allow a much greater degree of parallelism for
+	  both single-processor and multi-processor machines.</para>
+      </glossdef>
+    </glossentry>
+  </glossdiv>
+
   <glossdiv>
     <title>K</title>
 
     <glossentry id="kse">
       <glossterm>Kernel Scheduler Entities</glossterm>
       <acronym>KSE</acronym>
       <glossdef>
 	<para>A kernel-supported threading system.  See the <ulink
 	  url="http://www.FreeBSD.org/kse">project home page</ulink>
 	  for further details.</para>
       </glossdef>
     </glossentry>
 
     <glossentry>
       <glossterm>KSE</glossterm>
       <glosssee otherterm="kse">
     </glossentry>
   </glossdiv>
 
+  <glossdiv>
+    <title>L</title>
+
+    <glossentry id="lor">
+      <glossterm>Lock Order Reversal</glossterm>
+      <acronym>LOR</acronym>
+      <glossdef>
+	<para>The &os; kernel uses a number of resource locks to
+	  arbitrate contention for those resources.  A run-time
+	  lock diagnostic system found in &os.current; kernels
+	  (but removed for releases), called &man.witness.4;,
+	  detects the potential for deadlocks due to locking errors.
+	  (&man.witness.4; is actually slightly conservative, so
+	  it is possible to get false positives.)  A true positive
+	  report indicates that "if you were unlucky, a deadlock would
+	  have happened here".</para>
+
+	<para>True positive LORs tend to get fixed quickly, so
+	  check &a.current.url; and the
+	  <ulink url="http://sources.zabbadoz.net/freebsd/lor.html">
+	  LORs Seen</ulink> page before posting to the mailing lists.</para>
+      </glossdef>
+    </glossentry>
+
+    <glossentry>
+      <glossterm>LOR</glossterm>
+      <glosssee otherterm="lor">
+    </glossentry>
+  </glossdiv>
+
   <glossdiv>
     <title>M</title>
 
     <glossentry id="mfc">
       <glossterm>Merge From Current</glossterm>
       <acronym>MFC</acronym>
       <glossdef>
 	<para>To merge functionality or a patch from the -CURRENT
 	  branch to another, most often -STABLE.</para>
       </glossdef>
     </glossentry>
 
     <glossentry id="mfs">
       <glossterm>Merge From Stable</glossterm>
       <acronym>MFS</acronym>
       <glossdef>
 	<para>In the normal course of FreeBSD development, a change will
 	  be committed to the -CURRENT branch for testing before being
 	  merged to -STABLE.  On rare occassions, a change will go into
 	  -STABLE first and then be merged to -CURRENT.</para>
 
 	<para>This term is also used when a patch is merged from -STABLE
 	  to a security branch.</para>
 	<glossseealso otherterm="mfc">
       </glossdef>
     </glossentry>
 
     <glossentry>
       <glossterm>MFC</glossterm>
       <glosssee otherterm="mfc">
     </glossentry>
 
     <glossentry>
       <glossterm>MFS</glossterm>
       <glosssee otherterm="mfs">
     </glossentry>
+  </glossdiv>
+
+  <glossdiv>
+    <title>N</title>
+
+    <glossentry>
+      <glossterm>NDISUlator</glossterm>
+      <glosssee otherterm="projectevil">
+    </glossentry>
 
   </glossdiv>
 
+  <glossdiv>
+    <title>O</title>
+
+    <glossentry id="obe">
+      <glossterm>Overtaken By Events</glossterm>
+      <acronym>OBE</acronym>
+      <glossdef>
+	<para>Indicates a suggested change (such as a Problem Report
+	  or a feature request) which is no longer relevant or
+	  applicable due to such things as later changes to &os;,
+	  changes in networking standards, the affected hardware
+	  having since become obsolete, and so forth.</para>
+      </glossdef>
+    </glossentry>
+
+    <glossentry>
+      <glossterm>OBE</glossterm>
+      <glosssee otherterm="obe">
+    </glossentry>
+  </glossdiv>
+
   <glossdiv>
     <title>P</title>
 
+    <glossentry id="pointyhat">
+      <glossterm>Pointy Hat</glossterm>
+      <glossdef>
+	<para>A mythical piece of headgear, much like a
+	  <literal>dunce cap</literal>, awarded to any &os;
+	  committer who breaks the build, makes revision numbers
+	  go backwards, or creates any other kind of havoc in
+	  the source base.  Any committer worth his or her salt
+	  will soon accumulate a large collection.  The usage is
+	  (almost always?) humorous.</para>
+      </glossdef>
+    </glossentry>
+
     <glossentry id="pola">
       <glossterm>Principle Of Least Astonishment</glossterm>
       <acronym>POLA</acronym>
       <glossdef>
 	<para>As &os; evolves, changes visible to the user should be
 	  kept as unsurprising as possible.  For example, arbitrarily
 	  rearranging system startup variables in
 	  <filename>/etc/defaults/rc.conf</filename> violates
 	  <acronym>POLA</acronym>.  Developers consider
 	  <acronym>POLA</acronym> when contemplating user-visible
 	  system changes.</para>
       </glossdef>
     </glossentry>
 
     <glossentry>
       <glossterm>POLA</glossterm>
       <glosssee otherterm="pola">
     </glossentry>
+
+    <glossentry id="projectevil">
+      <glossterm>Project Evil</glossterm>
+      <glossdef>
+	<para>The working title for the <acronym>NDISulator</acronym>,
+	  written by Bill Paul, who named it referring to how awful
+	  it is (from a philosophical standpoint) to need to have
+	  something like this in the first place.  The
+	  <acronym>NDISulator</acronym> is a special compatibility
+	  module to allow Microsoft Windows&trade; NDIS miniport
+	  network drivers to be used with &os;/x86.  This is usually
+	  the only way to use cards where the driver is closed-source.
+	  See <filename>src/sys/compat/ndis/subr_ndis.c</filename>.</para>
+      </glossdef>
+    </glossentry>
+
   </glossdiv>
 </glossary>