Typo fixes in documentaion.

- Introduction fixed
- Requirements fixed
- Installation fixed partially

doc/installation.texi

@@ -13,9 +13,9 @@
 
 GCC at least 4.1 is strictly required for atomic builtins, but 4.2 or newer is recommended.
 Another requirement is _GNU_SOURCE support, otherwise it adapts to the compiler available features.
-Clang should work, but it is not tested nor officially supported.
+Clang should work, but it is not officially supported.
 
-Knot DNS build system relies on standard tools:
+Knot DNS build system relies on these standard tools:
 @itemize
 @item
 make
@@ -65,7 +65,7 @@ your system or distribution.  If not, zlib resides at
 liburcu is a LGPLv2.1 userspace RCU (read-copy-update)
 library. This data synchronization library provides read-side
 access which scales linearly with the number of cores. It does
-so by allowing multiples copies of a given data structure to
+so by allowing multiple copies of a given data structure to
 live at the same time, and by monitoring the data structure
 accesses to detect grace periods after which memory reclamation
 is possible.  (@url{http://lttng.org/urcu,Userspace RCU})
@@ -74,8 +74,7 @@ Binary packages for Debian can be found under liburcu1 for the
 library and liburcu-dev for development files.
 
 Minimum supported version of Userspace RCU library is 0.5.4,
-but we recommend using latest available version.  It is
-especially on non-Linux systems as we got some compatibility
+but we recommend using latest available version.  It is crucial especially on non-Linux systems as we got some compatibility
 patches accepted in later releases of Userspace RCU.
 OpenBSD,NetBSD and OS X platforms are supported from version 0.7.0.
 
@@ -109,7 +108,7 @@ Also, it has been reported that some platforms have broken LTO (Link time optimi
 support, you can disable that by @command{./configure --enable-lto=no}.
 
 If you want to add debug messages, there are two steps to do that.
-First you have to enable modules, that you are interested in.
+First you have to enable modules you are interested in.
 Available are: @code{server, zones, xfr, packet, dname, rr, ns, hash, compiler}.
 You can combine multiple modules as a comma-separated list.
 Then you can narrow the verbosity of the debugging message by specifying the
@@ -120,9 +119,6 @@ $ ./configure --enable-debug=server,packet --enable-debuglevel=brief
 $ ./configure --enable-debug=server,packet --enable-debuglevel=verbose
 @end example
 
-
-For example:  @command{}.
-
 In most simple case you can just run configure without any options.
 
 @example
@@ -133,7 +129,7 @@ In most simple case you can just run configure without any options.
 @subsection Compilation
 
 After running @command{./configure} you can compile
-Knot DNS by running make command, which will produce binaries
+Knot DNS by running @command{make} command, which will produce binaries
 and other related files.
 
 @example

doc/introduction.texi

@@ -19,7 +19,7 @@ is best suited for use on TLD domains but can reliably serve
 any other zone as well.
 
 Knot DNS benefits from its multi-threaded and mostly lock-free
-implementation which allow it to scale well on SMP systems and
+implementation which allows it to scale well on SMP systems and
 operate non-stop even when adding or removing zones.
 
 @node Knot DNS features

doc/requirements.texi

@@ -12,12 +12,12 @@
 @section Hardware requirements
 
 Knot DNS requirements are not very demanding for typical
-installations, and a comodity server or virtualized solution
+installations, and a comodity server or a virtualized solution
 will be sufficient in most cases.
 
-However please not that there are some scenarios that will
-require the administrator attention and a testing of exact
-requirements before deploying Knot DNS in a production.  These
+However please note that there are some scenarios that will
+require administrator attention and testing of exact
+requirements before deploying Knot DNS in production. These
 cases include deployment for a large number of zones (DNS
 hosting), a large number of records in one or more zones (TLD)
 or large number of requests.
@@ -25,7 +25,7 @@ or large number of requests.
 @node CPU requirements
 @section CPU requirements
 
-Knot DNS scales with the processing power and also the nubmer of available cores/CPUs.
+Knot DNS scales with processing power and also with the number of available cores/CPUs.
 
 There is no lower bound on the CPU requirements, but it should support memory barriers
 and CAS (i586 and newer).
@@ -33,16 +33,15 @@ and CAS (i586 and newer).
 @node Memory requirements
 @section Memory requirements
 
-Knot DNS implementation focuses on the performance and thus can
-be very demanding for the memory.  The rough estimate for memory
+Knot DNS implementation focuses on performance and thus can
+be very demanding for memory.  The rough estimate for memory
 requirements is 5-7 times of the size of the zone in text
-format.  Again this is only a estimate and you are advised to do
-your own measurements before deploying Knot DNS into the
-production.
+format.  Again this is only an estimate and you are advised to do
+your own measurements before deploying Knot DNS into production.
 
 Also note that to ensure uninterrupted serving of the zone, Knot DNS employs
 a Read-Copy-Update mechanism instead of locking and thus requires
-twice the amount of memory for the duration of the incoming transfers.
+twice the amount of memory for the duration of incoming transfers.
 
 @node Supported operating system
 @section Supported operating system