Merge branch 'master' of github.com:singularityware/singularityware.github.io

Author: vsoch

pages/docs/user-docs/docs-checks.md

@@ -6,7 +6,7 @@ folder: docs
 toc: false
 ---
 
-New to Singularity 2.4 is the ability to run container "checks" on demand. Checks can be anything from a filter for sensitive information, to an analysis installed binaries. A few defualt checks are installed with Singularity and others can be [added by the administrater](/docs-admin-checks).  Users can perform checks at build time or on demand:
+New to Singularity 2.4 is the ability to run container "checks" on demand. Checks can be anything from a filter for sensitive information, to an analysis of installed binaries. A few default checks are installed with Singularity and others can be [added by the administrator](/docs-admin-checks).  Users can perform checks at build time or on demand:
 
 {% include toc.html %}
 

pages/docs/user-docs/docs-flow.md

@@ -26,7 +26,7 @@ The diagram below is a visual depiction of how you can use Singularity to build
    <img style="max-width:900px" src="/assets/img/diagram/singularity-2.4-flow.png">
 </a>
 
-Singularity production images are immutable. This is a feature added as of Singularity 2.4, and it ensures a higher level of reproducibility and verification of images. To read more about the details, check out the  [build](docs-build-container) docs. However, immutability is not so great when you are testing, debugging, or otherwise want to quickly change your image. We will proceed by describing a typical workflow of developing first, building a final image, and using in production. 
+Singularity production images are immutable. This is a feature added as of Singularity 2.4, and it ensures a higher level of reproducibility and verification of images. To read more about the details, check out the  [build](docs-build-container) docs. However, immutability is not so great when you are testing, debugging, or otherwise want to quickly change your image. We will proceed by describing a typical workflow of developing first, building a final image, and using it in production. 
 
 ### 1. Development Commands
 If you want a writable image or folder for developing, you have two options:

pages/docs/user-docs/docs-instances.md

@@ -6,7 +6,7 @@ folder: docs
 toc: false
 ---
 
-Singularity 2.4 introduces the ability to run "container instances", allowing you to run services (*e.g. Nginx, MySQL, etc...*) using Singularity. A container instance, simply put, is a persistant and isolated version of the container image that runs in the background. 
+Singularity 2.4 introduces the ability to run "container instances", allowing you to run services (*e.g. Nginx, MySQL, etc...*) using Singularity. A container instance, simply put, is a persistent and isolated version of the container image that runs in the background. 
 
 {% include toc.html %}
 
@@ -22,7 +22,7 @@ With older versions of Singularity, if you were to do something like this, from
 
 Orphan process within unreachable namespaces!
 
-You would lose control of the process. It would still be running, but you couldn't easily kill or interface with it. This is a called a orphan process. Singularity versions less than 2.4 were not designed to handle running services properly.  
+You would lose control of the process. It would still be running, but you couldn't easily kill or interface with it. This is a called an orphan process. Singularity versions less than 2.4 were not designed to handle running services properly.  
 
 ## Container Instances in Singularity
 With Singularity 2.4 and the addition of container instances, the ability to cleanly, reliably, and safely run services in a container is here. First, let's put some commands that we want our instance to execute into a script. Let's call it a `startscript`. This fits into a definition file like so: