SIGNALS in rainbows-4.6.2 vs SIGNALS in rainbows-4.7.0

@@ -3,11 +3,11 @@
 In general, signals need only be sent to the master process.  However,
 the signals Rainbows! uses internally to communicate with the worker
 processes are documented here as well.  With the exception of TTIN/TTOU,
 signal handling matches the behavior of and {nginx}[http://nginx.net/]
 so it should be possible to easily share process management scripts
-between \Rainbows!, Unicorn and nginx.
+between \Rainbows!, unicorn and nginx.
 
 === Master Process
 
 * HUP - reload config file, app, and gracefully restart all workers
   If the "preload_app" directive is false (the default), then workers
@@ -58,18 +58,18 @@
   This currently does not wait for requests deferred to a separate
   thread when using EventMachine (when app.deferred?(env) => true)
 
 * USR1 - Reopen all logs owned by the worker process.
   See Unicorn::Util.reopen_logs for what is considered a log.
-  Unlike Unicorn, log files are reopened immediately in \Rainbows!
+  Unlike unicorn, log files are reopened immediately in \Rainbows!
   since worker processes are likely to be serving multiple clients
   simutaneously, we can't wait for all of them to finish.
 
 === Procedure to replace a running rainbows executable
 
 You may replace a running instance of rainbows with a new one without
 losing any incoming connections.  Doing so will reload all of your
-application code, Unicorn/Rainbows! config, Ruby executable, and all
+application code, unicorn/Rainbows! config, Ruby executable, and all
 libraries.  The only things that will not change (due to OS limitations)
 are:
 
 1. The path to the rainbows executable script.  If you want to change to
    a different installation of Ruby, you can modify the shebang