Typos in README

README.md

@@ -8,7 +8,7 @@ Intro
 
 contrary to the old unbit.it hosting platform, the new one is:
 
-- fully open source (oldest platforms was more-or-less proprietary software)
+- fully open source (old platform was more-or-less proprietary software)
 - can be installed on vanilla kernels
 - everyone can build it on his/her systems (and eventually buy commercial support from unbit.com ;)
 - will not rely on apache (so .htaccess will not be supported, unless you install apache in your container and proxy it via uWSGI routing)
@@ -31,20 +31,20 @@ Features and Goals
 - gather metrics and generate graphs
 - SNI is the only https/spdy supported approach
 - cron and external processes (like dbs) are managed as vassals
-- native (as uWSGI plugins) supported languages are Perl, CPython, PyPy, Ruby, Lua, Java and php (yes php apps works even without .htaccess...) 
-- you can easily proxy (in offloaded mode too) to external services, like nodejs, meteor, zope, elasticsearch ...
+- native (as uWSGI plugins) supported languages: Perl, CPython, PyPy, Ruby, Lua, Java and php (yes php apps works even without .htaccess...) 
+- you can easily proxy (in offloaded mode too) to external services like nodejs, meteor, zope, elasticsearch ...
 - Websockets support (in the routers/proxy) is enabled by default
 - Simple clustering and load-balancing
-- Sending emails is not part of the infrastructure (read:no SMTP services), but each container has transparent support for the nullmailer spool service (so you can use it to asynchronously send mails to external smtp services like mandrill and sendgrid)
-- /usr/local must be user-writable to allows custom installation/compilation (is bind-mounted to the container's home)
+- Sending emails is not part of the infrastructure (read: no SMTP services), but each container has transparent support for the nullmailer spool service (so you can use it to asynchronously send mails to external smtp services like mandrill and sendgrid)
+- /usr/local must be user-writable to allow custom installations/compilations (is bind-mounted to the container's home)
 - customers can buy a whole server, and create containers without supplier intervention
 - the unbit nss module exposes a name resolution facility to map `container`.local to the relevant ip
 - /run/shm (/dev/shm) is automatically mapped to the whole container memory
 - /var/run/utmp only exports sessions running in a container
 - xattrs and acls
-- allows mounting and managing loop block device via api
+- allows mounting and managing loop block device via APIs
 - The HTTP router can forward RTSP and chunked input requests
-- support for old CGI's (via uWSGI cgi plugin)
+- support for old CGIs (via uWSGI cgi plugin)
 - SFTP virtual chroot/jail is managed via the pysftpserver project
 - support in home etc/rc.local for distros without a uWSGI installation
 - support for custom distributions/images (https://github.com/unbit/uwsgi.it/blob/master/CustomDistros.md)
@@ -70,24 +70,24 @@ a legion manager
 
 a containers manager
 
-The 4th service manage vassals in /etc/uwsgi/vassals
+The 4th service manage vassals in /etc/uwsgi/vassals.
 
-Each vassal is spawned in a new Linux namespace and cgroup (all is native, no lxc is involved)
+Each vassal is spawned in a new Linux namespace and cgroup (all is native, no lxc is involved).
 
-An external app (well it could be hosted on the same infrastructure too) serves the api (a django app)
+An external app (well it could be hosted on the same infrastructure too) serves the API (a django app).
 
 All the customers vassals are created by the api.
 
-Each vassal spawns a sub-Emperor with uid and gid > 30000, the user (the owner of the container) can now use
+Each vassal spawns a sub-Emperor with uid and gid > 30000, the user (the owner of the container) can then use
 this sub-Emperor to spawn its vassals.
 
-The user can enter the container via ssh (a pam module calls setns() to attach to the running container)
+The user can login to the container via ssh (a pam module calls setns() to attach to the running container)
 
 The user can only view (and access) processes generated by the sub-Emperor (even the sub-Emperor is hidden)
 
-Domains to containers mapping is done via the uWSGI secured subscription system. An RSA key pair is generated by the control webapp (a Django app) for each registered customer. This key is used by the user to subscribe to the http/https router
+Domains to containers mapping is done via the uWSGI secured subscription system. An RSA key pair is generated by the control webapp (a Django app) for each registered customer. This key is used by the user to subscribe to the http/https router.
 
-Subscriptions can pass SSL certificates to the router that reconfigure it to map them to domains (via SNI)
+Subscriptions can pass SSL certificates to the router that reconfigure it to map them to domains (via SNI).
 
 Four perl processes manage the infrastruture configuration:
 
@@ -102,7 +102,7 @@ TODO
 ----
 
 - Map public ipv4/ipv6 addresses directly to a container (via NAT)
-- Implement sub-users concept for the api (maybe as subuser@user)
+- Implement sub-users concept for the API (maybe as subuser@user)
 - Add support for https://github.com/unbit/spockfs mounts (maybe in the same way as loopboxes ?)
 - fastrouter-only implementation for nginx integration
 - is SPDY/HTTP2 support whorty ?