21 files changed, 71 insertions, 71 deletions
diff --git a/docs/glossary.rst b/docs/glossary.rst
index 16a719e10..9a94d72bb 100644
--- a/docs/glossary.rst
+++ b/docs/glossary.rst
@@ -1021,12 +1021,12 @@ Glossary
      A package which logs Pyramid application exception (error) information
      to a standard Python logger.  This add-on is most useful when
      used in production applications, because the logger can be configured to
-     log to a file, to UNIX syslog, to the Windows Event Log, or even to
+     log to a file, to Unix syslog, to the Windows Event Log, or even to
      email. See its `documentation
      <https://docs.pylonsproject.org/projects/pyramid_exclog/en/latest/>`_.
 
    console script
-     A script written to the ``bin`` (on UNIX, or ``Scripts`` on Windows)
+     A script written to the ``bin`` (on Unix, or ``Scripts`` on Windows)
      directory of a Python installation or :term:`virtual environment` as the
      result of running ``pip install`` or ``pip install -e .``.
 
@@ -1075,14 +1075,14 @@ Glossary
       :class:`pyramid.interfaces.IAssetDescriptor`.
 
    Waitress
-      A :term:`WSGI` server that runs on UNIX and Windows under Python 2.7+
+      A :term:`WSGI` server that runs on Unix and Windows under Python 2.7+
       and Python 3.3+.  Projects generated via Pyramid cookiecutters use
       Waitress as a WGSI server.  See
       https://docs.pylonsproject.org/projects/waitress/en/latest/ for detailed
       information.
 
    Green Unicorn
-      Aka ``gunicorn``, a fast :term:`WSGI` server that runs on UNIX under
+      Aka ``gunicorn``, a fast :term:`WSGI` server that runs on Unix under
       Python 2.6+ or Python 3.1+.  See http://gunicorn.org/ for detailed 
       information.
 
@@ -1131,7 +1131,7 @@ Glossary
       ``pyvenv`` command for `creating virtual environments on Python 3.4 and
       3.5
       <https://packaging.python.org/tutorials/installing-packages/#creating-virtual-environments>`_,
-      but it was deprecated in 3.6 in favor of ``python3 -m venv`` on UNIX or
+      but it was deprecated in 3.6 in favor of ``python3 -m venv`` on Unix or
       ``python -m venv`` on Windows, which is backward compatible on Python
       3.3 and greater.
 
diff --git a/docs/narr/firstapp.rst b/docs/narr/firstapp.rst
index 7019d4126..5eb067fe2 100644
--- a/docs/narr/firstapp.rst
+++ b/docs/narr/firstapp.rst
@@ -25,7 +25,7 @@ When this code is inserted into a Python script named ``helloworld.py`` and
 executed by a Python interpreter which has the :app:`Pyramid` software
 installed, an HTTP server is started on TCP port 8080.
 
-On UNIX:
+On Unix:
 
 .. code-block:: bash
 
diff --git a/docs/narr/i18n.rst b/docs/narr/i18n.rst
index 329193239..da0f714f5 100644
--- a/docs/narr/i18n.rst
+++ b/docs/narr/i18n.rst
@@ -256,10 +256,10 @@ In order for the commands related to working with ``gettext`` translation files
 to work properly, you will need to have :term:`Lingua` and :term:`Gettext`
 installed into the same environment in which :app:`Pyramid` is installed.
 
-Installation on UNIX
+Installation on Unix
 ++++++++++++++++++++
 
-Gettext is often already installed on UNIX systems. You can check if it is
+Gettext is often already installed on Unix systems. You can check if it is
 installed by testing if the ``msgfmt`` command is available. If it is not
 available you can install it through the packaging system from your OS; the
 package name is almost always ``gettext``. For example on a Debian or Ubuntu
diff --git a/docs/narr/install.rst b/docs/narr/install.rst
index c36f4f391..7947e6c73 100644
--- a/docs/narr/install.rst
+++ b/docs/narr/install.rst
@@ -24,8 +24,8 @@ the following sections.
     As of this writing, :app:`Pyramid` is tested against Python 2.7,
     Python 3.4, Python 3.5, Python 3.6, and PyPy.
 
-:app:`Pyramid` is known to run on all popular UNIX-like systems such as Linux,
-Mac OS X, and FreeBSD, as well as on Windows platforms.  It is also known to
+:app:`Pyramid` is known to run on all popular Unix-like systems such as Linux,
+macOS, and FreeBSD, as well as on Windows platforms.  It is also known to
 run on :term:`PyPy` (1.9+).
 
 :app:`Pyramid` installation does not require the compilation of any C code.
@@ -67,12 +67,12 @@ If you use an installer for your Python, then you can skip to the section
 
 .. _if-you-don-t-yet-have-a-python-interpreter-unix:
 
-If You Don't Yet Have a Python Interpreter (UNIX)
+If You Don't Yet Have a Python Interpreter (Unix)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-If your system doesn't have a Python interpreter, and you're on UNIX, you can
+If your system doesn't have a Python interpreter, and you're on Unix, you can
 either install Python using your operating system's package manager *or* you
-can install Python from source fairly easily on any UNIX system that has
+can install Python from source fairly easily on any Unix system that has
 development tools.
 
 .. seealso:: See the official Python documentation :ref:`Using Python on Unix
@@ -162,12 +162,12 @@ application, rather than being installed system wide.
 
 
 .. index::
-   single: installing on UNIX
+   single: installing on Unix
    single: installing on Mac OS X
 
 .. _installing_unix:
 
-Installing :app:`Pyramid` on a UNIX System
+Installing :app:`Pyramid` on a Unix System
 ------------------------------------------
 
 After installing Python as described previously in :ref:`for-mac-os-x-users` or
diff --git a/docs/narr/project.rst b/docs/narr/project.rst
index 4940543f6..ee40f212e 100644
--- a/docs/narr/project.rst
+++ b/docs/narr/project.rst
@@ -103,7 +103,7 @@ If prompted for the first item, accept the default ``yes`` by hitting return.
 
 We then run through the following commands.
 
-On UNIX:
+On Unix:
 
 .. code-block:: bash
 
@@ -188,7 +188,7 @@ in the ``bin`` (or ``Scripts`` on Windows) directory of your virtual Python
 environment.  Your terminal's current working directory *must* be the newly
 created project directory.
 
-On UNIX:
+On Unix:
 
 .. code-block:: bash
 
@@ -200,7 +200,7 @@ Or on Windows:
 
     %VENV%\Scripts\pip install -e .
 
-Elided output from a run of this command on UNIX is shown below:
+Elided output from a run of this command on Unix is shown below:
 
 .. code-block:: bash
 
@@ -226,7 +226,7 @@ Running the Tests for Your Application
 To run unit tests for your application, you must first install the testing
 dependencies.
 
-On UNIX:
+On Unix:
 
 .. code-block:: bash
 
@@ -242,7 +242,7 @@ Once the testing requirements are installed, then you can run the tests using
 the ``py.test`` command that was just installed in the ``bin`` directory of
 your virtual environment.
 
-On UNIX:
+On Unix:
 
 .. code-block:: bash
 
@@ -254,7 +254,7 @@ On Windows:
 
     %VENV%\Scripts\py.test -q
 
-Here's sample output from a test run on UNIX:
+Here's sample output from a test run on Unix:
 
 .. code-block:: bash
 
@@ -307,7 +307,7 @@ Once a project is installed for development, you can run the application it
 represents using the ``pserve`` command against the generated configuration
 file.  In our case, this file is named ``development.ini``.
 
-On UNIX:
+On Unix:
 
 .. code-block:: bash
 
@@ -319,7 +319,7 @@ On Windows:
 
     %VENV%\Scripts\pserve development.ini
 
-Here's sample output from a run of ``pserve`` on UNIX:
+Here's sample output from a run of ``pserve`` on Unix:
 
 .. code-block:: bash
 
@@ -394,7 +394,7 @@ module your project uses will cause the server to restart.  This typically
 makes development easier, as changes to Python code made within a
 :app:`Pyramid` application is not put into effect until the server restarts.
 
-For example, on UNIX:
+For example, on Unix:
 
 .. code-block:: text
 
diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst
index bc3e913ff..1ccab9d3c 100644
--- a/docs/narr/templates.rst
+++ b/docs/narr/templates.rst
@@ -52,7 +52,7 @@ directory containing the file which defines the view configuration. In this
 case, this is the directory containing the file that defines the
 ``sample_view`` function.  Although a renderer path is usually just a simple
 relative pathname, a path named as a renderer can be absolute, starting with a
-slash on UNIX or a drive letter prefix on Windows. The path can alternatively
+slash on Unix or a drive letter prefix on Windows. The path can alternatively
 be an :term:`asset specification` in the form
 ``some.dotted.package_name:relative/path``. This makes it possible to address
 template assets which live in another package.  For example:
@@ -317,7 +317,7 @@ Similar renderer configuration can be done imperatively.  See
     See also :ref:`built_in_renderers`.
 
 Although a renderer path is usually just a simple relative pathname, a path
-named as a renderer can be absolute, starting with a slash on UNIX or a drive
+named as a renderer can be absolute, starting with a slash on Unix or a drive
 letter prefix on Windows.  The path can alternatively be an :term:`asset
 specification` in the form ``some.dotted.package_name:relative/path``, making
 it possible to address template assets which live in another package.
diff --git a/docs/narr/upgrading.rst b/docs/narr/upgrading.rst
index 9568a6203..ba9a4d041 100644
--- a/docs/narr/upgrading.rst
+++ b/docs/narr/upgrading.rst
@@ -197,7 +197,7 @@ deprecation warnings won't be executed.
 
 In this circumstance, you can start your application interactively under a
 server run with the ``PYTHONWARNINGS`` environment variable set to ``default``.
-On UNIX, you can do that via:
+On Unix, you can do that via:
 
 .. code-block:: bash
 
diff --git a/docs/narr/viewconfig.rst b/docs/narr/viewconfig.rst
index 06b4d99eb..c463d297e 100644
--- a/docs/narr/viewconfig.rst
+++ b/docs/narr/viewconfig.rst
@@ -134,7 +134,7 @@ Non-Predicate Arguments
   When the renderer is a path—although a path is usually just a simple relative
   pathname (e.g., ``templates/foo.pt``, implying that a template named "foo.pt"
   is in the "templates" directory relative to the directory of the current
-  :term:`package`)—the path can be absolute, starting with a slash on UNIX or a
+  :term:`package`)—the path can be absolute, starting with a slash on Unix or a
   drive letter prefix on Windows.  The path can alternatively be a :term:`asset
   specification` in the form ``some.dotted.package_name:relative/path``, making
   it possible to address template assets which live in a separate package.
diff --git a/docs/quick_tour.rst b/docs/quick_tour.rst
index a25417e40..837dce62b 100644
--- a/docs/quick_tour.rst
+++ b/docs/quick_tour.rst
@@ -56,7 +56,7 @@ For Windows:
 Of course Pyramid runs fine on Python 2.7+, as do the examples in this *Quick
 Tour*. We're showing Python 3 for simplicity. (Pyramid had production support
 for Python 3 in October 2011.) Also for simplicity, the remaining examples will
-show only UNIX commands.
+show only Unix commands.
 
 .. seealso:: See also:
     :ref:`Quick Tutorial section on Requirements <qtut_requirements>`,
diff --git a/docs/quick_tutorial/requirements.rst b/docs/quick_tutorial/requirements.rst
index 0da56ca0b..746af8207 100644
--- a/docs/quick_tutorial/requirements.rst
+++ b/docs/quick_tutorial/requirements.rst
@@ -33,7 +33,7 @@ This *Quick Tutorial* is based on:
   projects* (a directory with packaging information and *Python packages* of
   working code.)
 
-* **Unix commands**. Commands in this tutorial use UNIX syntax and paths.
+* **Unix commands**. Commands in this tutorial use Unix syntax and paths.
   Windows users should adjust commands accordingly.
 
 .. note::
@@ -89,11 +89,11 @@ will reside as we proceed through the tutorial:
                 │   └── app.py
                 └── setup.py
 
-For Linux, the commands to do so are as follows:
+For macOS and Linux, the commands to do so are as follows:
 
 .. code-block:: bash
 
-    # Mac and Linux
+    # macOS and Linux
     cd ~
     mkdir -p projects/quick_tutorial
     cd projects/quick_tutorial
@@ -129,7 +129,7 @@ environment`. We set an environment variable to save typing later.
 
 .. code-block:: bash
 
-    # Mac and Linux
+    # macOS and Linux
     export VENV=~/projects/quick_tutorial/env
 
 .. code-block:: doscon
@@ -150,7 +150,7 @@ environment variable.
 
 .. code-block:: bash
 
-    # Mac and Linux
+    # macOS and Linux
     python3 -m venv $VENV
 
 .. code-block:: doscon
@@ -171,7 +171,7 @@ time of its release.
 
 .. code-block:: bash
 
-    # Mac and Linux
+    # macOS and Linux
     $VENV/bin/pip install --upgrade pip setuptools
 
 .. code-block:: doscon
@@ -193,7 +193,7 @@ part is pretty easy. We'll also install a WSGI server, Waitress.
 
 .. parsed-literal::
 
-    # Mac and Linux
+    # macOS and Linux
     $VENV/bin/pip install "pyramid==\ |release|\ " waitress
 
     # Windows
diff --git a/docs/tutorials/wiki/background.rst b/docs/tutorials/wiki/background.rst
index c583b375c..61383c2d6 100644
--- a/docs/tutorials/wiki/background.rst
+++ b/docs/tutorials/wiki/background.rst
@@ -11,7 +11,7 @@ familiar to someone with :term:`Zope` experience.  It uses
 URLs to code.  It can also be followed by people without any prior
 Python web framework experience.
 
-To code along with this tutorial, the developer will need a UNIX
+To code along with this tutorial, the developer will need a Unix
 machine with development tools (Mac OS X with XCode, any Linux or BSD
 variant, and so on) *or* a Windows system of any kind.
 
diff --git a/docs/tutorials/wiki/definingviews.rst b/docs/tutorials/wiki/definingviews.rst
index 0bdb05a56..e4183b8f2 100644
--- a/docs/tutorials/wiki/definingviews.rst
+++ b/docs/tutorials/wiki/definingviews.rst
@@ -64,7 +64,7 @@ the newly added dependency distribution.
 Make sure your current working directory is the root of the project (the
 directory in which ``setup.py`` lives) and execute the following command.
 
-On UNIX:
+On Unix:
 
 .. code-block:: bash
 
diff --git a/docs/tutorials/wiki/distributing.rst b/docs/tutorials/wiki/distributing.rst
index 3937fcff8..36d00adb4 100644
--- a/docs/tutorials/wiki/distributing.rst
+++ b/docs/tutorials/wiki/distributing.rst
@@ -9,7 +9,7 @@ using the ``setup.py sdist`` command.  The following commands assume your
 current working directory contains the ``tutorial`` package and the
 ``setup.py`` file.
 
-On UNIX:
+On Unix:
 
 .. code-block:: bash
 
diff --git a/docs/tutorials/wiki/installation.rst b/docs/tutorials/wiki/installation.rst
index 0bd3d40a5..71fd0a957 100644
--- a/docs/tutorials/wiki/installation.rst
+++ b/docs/tutorials/wiki/installation.rst
@@ -23,9 +23,9 @@ We will use a :term:`cookiecutter` to create a Python package project from a Pyt
 Generate a Pyramid project from a cookiecutter
 ----------------------------------------------
 
-We will create a Pyramid project in your home directory for UNIX or at the root for Windows. It is assumed you know the path to where you installed ``cookiecutter``. Issue the following commands and override the defaults in the prompts as follows.
+We will create a Pyramid project in your home directory for Unix or at the root for Windows. It is assumed you know the path to where you installed ``cookiecutter``. Issue the following commands and override the defaults in the prompts as follows.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -55,7 +55,7 @@ If prompted for the first item, accept the default ``yes`` by hitting return.
 Change directory into your newly created project
 ------------------------------------------------
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -75,7 +75,7 @@ Set and use a ``VENV`` environment variable
 
 We will set the ``VENV`` environment variable to the absolute path of the virtual environment, and use it going forward.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -93,7 +93,7 @@ On Windows
 Create a virtual environment
 ----------------------------
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -121,7 +121,7 @@ Python 3.6:
 Upgrade packaging tools in the virtual environment
 --------------------------------------------------
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -143,7 +143,7 @@ Installing the project in development mode
 
 In order to do development on the project easily, you must "register" the project as a development egg in your workspace. We will install testing requirements at the same time. We do so with the following command.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -198,7 +198,7 @@ requirements, you may run the tests for the project. The following commands
 provide options to py.test that specify the module for which its tests shall be
 run, and to run py.test in quiet mode.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -231,7 +231,7 @@ tests.
 We've already installed the ``pytest-cov`` package into our virtual
 environment, so we can run the tests with coverage.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -280,7 +280,7 @@ These configuration files are ``pytest.ini`` and ``.coveragerc``, located at
 the root of your package. Without these defaults, we would need to specify the
 path to the module on which we want to run tests and coverage.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -311,7 +311,7 @@ Start the application
 Start the application. See :ref:`what_is_this_pserve_thing` for more
 information on ``pserve``.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
diff --git a/docs/tutorials/wiki/tests.rst b/docs/tutorials/wiki/tests.rst
index 798ef4447..c3a1ca79a 100644
--- a/docs/tutorials/wiki/tests.rst
+++ b/docs/tutorials/wiki/tests.rst
@@ -56,7 +56,7 @@ We can run these tests by using ``py.test`` similarly to how we did in
 already been satisfied and ``py.test`` and coverage have already been
 configured, so we can jump right to running tests.
 
-On UNIX:
+On Unix:
 
 .. code-block:: bash
 
diff --git a/docs/tutorials/wiki2/background.rst b/docs/tutorials/wiki2/background.rst
index ee7dfe36f..ded6bc9c3 100644
--- a/docs/tutorials/wiki2/background.rst
+++ b/docs/tutorials/wiki2/background.rst
@@ -11,7 +11,7 @@ familiar to someone with SQL database experience.  It uses
 URLs to code.  It can also be followed by people without any prior
 Python web framework experience.
 
-To code along with this tutorial, the developer will need a UNIX
+To code along with this tutorial, the developer will need a Unix
 machine with development tools (Mac OS X with XCode, any Linux or BSD
 variant, etc.) *or* a Windows system of any kind.
 
diff --git a/docs/tutorials/wiki2/definingmodels.rst b/docs/tutorials/wiki2/definingmodels.rst
index d0674e283..9159027c4 100644
--- a/docs/tutorials/wiki2/definingmodels.rst
+++ b/docs/tutorials/wiki2/definingmodels.rst
@@ -53,7 +53,7 @@ the newly added dependency distribution.
 Make sure your current working directory is the root of the project (the
 directory in which ``setup.py`` lives) and execute the following command.
 
-On UNIX:
+On Unix:
 
 .. code-block:: bash
 
@@ -165,7 +165,7 @@ Migrate the database with Alembic
 
 Now that we have written our models, we need to modify the database schema to reflect the changes to our code. Let's generate a new revision, then upgrade the database to the latest revision (head).
 
-On UNIX:
+On Unix:
 
 .. code-block:: bash
 
diff --git a/docs/tutorials/wiki2/distributing.rst b/docs/tutorials/wiki2/distributing.rst
index e558748d4..0eff63461 100644
--- a/docs/tutorials/wiki2/distributing.rst
+++ b/docs/tutorials/wiki2/distributing.rst
@@ -9,7 +9,7 @@ using the ``setup.py sdist`` command.  The following commands assume your
 current working directory contains the ``tutorial`` package and the
 ``setup.py`` file.
 
-On UNIX:
+On Unix:
 
 .. code-block:: bash
 
diff --git a/docs/tutorials/wiki2/installation.rst b/docs/tutorials/wiki2/installation.rst
index 581ec7f09..1fa7e21d7 100644
--- a/docs/tutorials/wiki2/installation.rst
+++ b/docs/tutorials/wiki2/installation.rst
@@ -35,9 +35,9 @@ We will use a :term:`cookiecutter` to create a Python package project from a Pyt
 Generate a Pyramid project from a cookiecutter
 ----------------------------------------------
 
-We will create a Pyramid project in your home directory for UNIX or at the root for Windows. It is assumed you know the path to where you installed ``cookiecutter``. Issue the following commands and override the defaults in the prompts as follows.
+We will create a Pyramid project in your home directory for Unix or at the root for Windows. It is assumed you know the path to where you installed ``cookiecutter``. Issue the following commands and override the defaults in the prompts as follows.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -67,7 +67,7 @@ If prompted for the first item, accept the default ``yes`` by hitting return.
 Change directory into your newly created project
 ------------------------------------------------
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -87,7 +87,7 @@ Set and use a ``VENV`` environment variable
 
 We will set the ``VENV`` environment variable to the absolute path of the virtual environment, and use it going forward.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -105,7 +105,7 @@ On Windows
 Create a virtual environment
 ----------------------------
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -133,7 +133,7 @@ Python 3.6:
 Upgrade packaging tools in the virtual environment
 --------------------------------------------------
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -155,7 +155,7 @@ Installing the project in development mode
 
 In order to do development on the project easily, you must "register" the project as a development egg in your workspace. We will install testing requirements at the same time. We do so with the following command.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -207,7 +207,7 @@ We use :term:`Alembic` to manage our database initialization and migrations.
 
 Generate your first revision.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -248,7 +248,7 @@ The output to your console should be something like this:
 
 Upgrade to that revision.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -303,7 +303,7 @@ Load default data
 
 Load default data into the database using a :term:`console script`. Type the following command, making sure you are still in the ``tutorial`` directory (the directory with a ``development.ini`` in it):
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -345,7 +345,7 @@ requirements, you may run the tests for the project. The following commands
 provide options to py.test that specify the module for which its tests shall be
 run, and to run py.test in quiet mode.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -378,7 +378,7 @@ tests.
 We've already installed the ``pytest-cov`` package into our virtual
 environment, so we can run the tests with coverage.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -434,7 +434,7 @@ These configuration files are ``pytest.ini`` and ``.coveragerc``, located at
 the root of your package. Without these defaults, we would need to specify the
 path to the module on which we want to run tests and coverage.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
@@ -465,7 +465,7 @@ Start the application
 Start the application. See :ref:`what_is_this_pserve_thing` for more
 information on ``pserve``.
 
-On UNIX
+On Unix
 ^^^^^^^
 
 .. code-block:: bash
diff --git a/docs/tutorials/wiki2/tests.rst b/docs/tutorials/wiki2/tests.rst
index f856f837e..f3f89fe9c 100644
--- a/docs/tutorials/wiki2/tests.rst
+++ b/docs/tutorials/wiki2/tests.rst
@@ -94,7 +94,7 @@ Running the tests
 
 We can run these tests similarly to how we did in :ref:`running_tests`, but first delete the SQLite database ``tutorial.sqlite``. If you do not delete the database, then you will see an integrity error when running the tests.
 
-On UNIX:
+On Unix:
 
 .. code-block:: bash
 
diff --git a/docs/whatsnew-1.1.rst b/docs/whatsnew-1.1.rst
index a5c7f3393..2427a0074 100644
--- a/docs/whatsnew-1.1.rst
+++ b/docs/whatsnew-1.1.rst
@@ -395,7 +395,7 @@ Deprecations and Behavior Differences
    when porting your application from an older version of Pyramid.  Use the
    ``PYTHONWARNINGS`` environment variable with the value ``all`` in the
    shell you use to invoke ``paster serve`` to see these warnings, e.g. on
-   UNIX, ``PYTHONWARNINGS=all $VENV/bin/paster serve development.ini``.
+   Unix, ``PYTHONWARNINGS=all $VENV/bin/paster serve development.ini``.
    Python 2.5 and 2.6 show deprecation warnings by default,
    so this is unnecessary there.
    All deprecation warnings are emitted to the console.