diff --git a/src/_layouts/home.html b/src/_layouts/home.html
index 6db2f10..65f2917 100644
--- a/src/_layouts/home.html
+++ b/src/_layouts/home.html
@@ -1,207 +1,204 @@
 ---
 layout: clusterlabs
 ---
 
 <!-- Banner -->
 <section id="banner">
   <div class="content">
 	<header>
 	  <h1>ClusterLabs</h1>
 	  <p>Open&nbsp;Source <strong>High&nbsp;Availability</strong> Cluster&nbsp;Stack</p>
 	</header>
 	<p>
 	  The ClusterLabs stack unifies a large group of Open Source projects related to
 	  <strong>High Availability</strong> into a cluster offering suitable
 	  for both small and large deployments. Together,
 	  <a href="/corosync.html">Corosync</a>,
 	  <a href="/pacemaker/">Pacemaker</a>,
 	  <a href="https://linbit.com/">DRBD</a>,
 	  <a href="https://www.alteeve.com/w/ScanCore">ScanCore</a>,
 	  and many other projects have been enabling detection and recovery of
 	  machine and application-level failures in production clusters since
 	  1999. The ClusterLabs stack supports practically any redundancy
 	  configuration imaginable.</p>
 	<ul class="actions">
 	  <li><a href="#content" class="button big">Learn More</a></li>
 	</ul>
   </div>
-  <span class="image object">
-    {% image clusterlabs3.svg %}
-  </span>
 </section>
 
 <section>
     <header class="major">
       <h2>Quick Overview</h2>
     </header>
   <div class="boxes">
    <article>
      <a href="{% asset_path Deploy.png %}" class="image">{% image Deploy-small.png %}</a>
      <h3>Deploy</h3>
      <p>
        We support many deployment scenarios, from the simplest
        2-node standby cluster to a 32-node active/active
        configuration.
 
        We can also dramatically reduce hardware costs by allowing
        several active/passive clusters to be combined and share a common
        backup node.
      </p>
    </article>
 
    <article>
      <a href="{% asset_path Monitor.png %}" class="image">{% image Monitor-small.png %}</a>
      <h3>Monitor</h3>
      <p>
        We monitor the system for both hardware and software failures.
 
        In the event of a failure, we will automatically recover
        your application and make sure it is available from one
        of the remaning machines in the cluster.
      </p>
    </article>
    
    <article>
      <a href="{% asset_path Recover.png %}" class="image">{% image Recover-small.png %}</a>
      <h3>Recover</h3>
      <p>
        After a failure, we use advanced algorithms to quickly
        determine the optimum locations for services based on
        relative node preferences and/or requirements to run with
        other cluster services (we call these "constraints").
      </p>
    </article>
    </div>
  </section>
 
   <section>
     <header class="major">
       <h2 id="why">Why clusters</h2>
     </header>
 
     <p>
       At its core, a cluster is a distributed finite state
       machine capable of co-ordinating the startup and recovery
       of inter-related services across a set of machines.
     </p>
     <blockquote class="pullquote">
       System HA is possible without a cluster manager, but you save many headaches using one anyway
     </blockquote>
     <p>
       Even a distributed and/or replicated application that is
       able to survive the failure of one or more components can
       benefit from a higher level cluster:
       <ul>
         <li>awareness of other applications in the stack</li>
         <li>a shared <a href="https://en.wikipedia.org/wiki/Quorum_%28Distributed_Systems%29">quorum</a> implementation and calculation</li>
         <li>data integrity through fencing (a non-responsive process does not imply it is not doing anything)</li>
         <li>automated recovery of instances to ensure capacity</li>
       </ul>
     </p>
     <p>
       While SYS-V init replacements like systemd can provide
       deterministic recovery of a complex stack of services, the
       recovery is limited to one machine and lacks the context
       of what is happening on other machines - context that is
       crucial to determine the difference between a local
       failure, clean startup or recovery after a total site
       failure.
     </p>
   </section>
 
   <section>
     <header class="major">
       <h2 id="features">Features</h2>
     </header>
 
     <p>
       The ClusterLabs stack, incorporating <a href="/corosync.html">Corosync</a>
       and <a href="/pacemaker/">Pacemaker</a> defines
       an <a href="https://en.wikipedia.org/wiki/Open_source">Open Source</a>,
       <a href="https://en.wikipedia.org/wiki/High_availability">High Availability</a>
        <a href="https://en.wikipedia.org/wiki/Cluster_(computing)">cluster</a>
        offering suitable for both small and large deployments.
     </p>
 
     <ul>
       <li>Detection and recovery of machine and application-level failures</li>
       <li>Supports practically any <a href="https://wiki.clusterlabs.org/wiki/ClusterTypes">redundancy configuration</a></li>
       <li>Supports both <a href="https://en.wikipedia.org/wiki/Quorum_%28Distributed_Systems%29">quorate</a> and <a href="https://web.archive.org/web/20110727185030/http://devresources.linux-foundation.org/dev/clusters/docs/ResourceDrivenClusters.pdf">resource-driven</a> clusters</li>
       <li>Configurable <a href="/pacemaker/doc/2.1/Pacemaker_Explained/html/options.html#cluster-options">strategies</a> for dealing with <a href="https://en.wikipedia.org/wiki/Quorum_%28Distributed_Systems%29">quorum</a> loss (when multiple machines fail)</li>
       <li>Supports application <a href="/pacemaker/doc/2.1/Pacemaker_Explained/html/constraints.html#specifying-the-order-in-which-resources-should-start-stop">startup/shutdown ordering</a>, without requiring the applications to run on the same node</li>
       <li>Supports applications that must or must not run on the <a href="/pacemaker/doc/2.1/Pacemaker_Explained/html/constraints.html#placing-resources-relative-to-other-resources">same node</a></li>
       <li>Supports applications which need to be active on <a href="/pacemaker/doc/2.1/Pacemaker_Explained/html/advanced-resources.html#clones-resources-that-can-have-multiple-active-instances">multiple nodes</a></li>
       <li>Supports applications with dual roles (<a href="https://clusterlabs.org/pacemaker/doc/2.1/Pacemaker_Explained/html/advanced-resources.html#promotable-clones">promoted and unpromoted</a>)<br/><br/></li>
       <li>Provably correct response to any failure or cluster state. The cluster's
           response to any stimuli can be tested offline <i>before</i> the condition exists
       </li>
     </ul>
 
   </section>
 
   <section>
     <header class="major">
       <h2 id="components">Components</h2>
     </header>
   
     <blockquote class="pullquote">
     "The definitive open-source high-availability stack for the Linux
     platform builds upon the Pacemaker cluster resource manager."<br />
     -- <cite>LINUX Journal</cite>,
     <a href="http://www.linuxjournal.com/content/ahead-pack-pacemaker-high-availability-stack">"Ahead
     of the Pack: the Pacemaker High-Availability Stack"</a>
     </blockquote>
     <p>A Pacemaker stack is built on five core components:  
     <ul>
       <li>libQB - core services (logging, IPC, etc)</li>
       <li>Corosync - Membership, messaging and quorum</li>
       <li>Resource agents - A collection of scripts that interact with the underlying services managed by the cluster</li>
       <li>Fencing agents - A collection of scripts that interact with network power switches and SAN devices to isolate cluster members</li>
       <li>Pacemaker itself</li>
     </ul>
     </p>
 
     <p>
       We describe each of these in <a href="/components.html">more detail</a> as well as other optional components such as CLIs and GUIs.
     </p>
 
   </section>
 
   <section>
     <header class="major">
       <h2 id="background">Background</h2>
     </header>
 
     <p>
       Pacemaker has been around
       since <a href="https://www.openhub.net/p/pacemaker/analyses/latest/languages_summary">2004</a>
       and is primarily a collaborative effort
       between <a href="https://www.redhat.com/">Red Hat</a>
       and <a href="https://www.suse.com/">SUSE</a>, however we also
       receive considerable help and support from the folks
       at <a href="https://www.linbit.com/">LinBit</a> and the community in
       general.
     </p>
     <p>
       Corosync also began life in <a href="https://www.ohloh.net/p/corosync/analyses/latest/languages_summary">2004</a>
       but was then part of the <a href="https://www.ohloh.net/p/openAIS">OpenAIS project</a>.
       It is primarily a <a href="https://www.redhat.com/">Red Hat</a> initiative,
       with considerable help and support from the folks in the community.
     </p>
     <p>
       The core ClusterLabs team is made up of full-time
       developers from Australia, Austria, Canada, China, Czech
       Repulic, England, Germany, Sweden and the USA.  Contributions to
       the code or documentation are always welcome.
     </p>
     <p>
       The ClusterLabs stack ships with most modern enterprise
       distributions and has been deployed in many critical
       environments including Deutsche Flugsicherung GmbH
       (<a href="http://www.dfs.de/dfs_homepage/en/">DFS</a>)
       which uses Pacemaker to ensure
       its <a href="http://www.novell.com/success/dfs.html">air
       traffic control systems</a> are always available.
     </p>
   </section>