typos

Worker.md

@@ -57,7 +57,7 @@ Picture below is internal architecture of worker which shows its defined classes
 
 ### Dependencies
 
-Worker specific requirements are written in this section. It covers only basic requirements, additional runtimes or tools may be needed depending on type of use. The package names are for CentOS in not specified otherwise. 
+Worker specific requirements are written in this section. It covers only basic requirements, additional runtimes or tools may be needed depending on type of use. The package names are for CentOS if not specified otherwise. 
 
 - ZeroMQ in version at least 4.0, packages `zeromq` and `zeromq-devel` (`libzmq3-dev` on Debian)
 - YAML-CPP library, `yaml-cpp` and `yaml-cpp-devel` (`libyaml-cpp0.5v5` and `libyaml-cpp-dev` on Debian)
@@ -133,7 +133,7 @@ install> win-build.cmd -package
 All build binaries and cmake temporary files can be found in *build* folder, 
 classically there will be subfolder *Release* which will contain compiled 
 application with all needed dlls. Once if clickable installation binary is 
-created, it can be found in *build* folder named something like 
+created, it can be found in *build* folder under name 
 *recodex-worker-VERSION-win32.exe*. Sample screenshot can be found on following picture.
 
 ![NSIS Installation](https://github.com/ReCodEx/wiki/blob/master/images/nsis_installation.png)
@@ -141,7 +141,7 @@ created, it can be found in *build* folder named something like
 
 ## Configuration and usage
 
-Following text describes how to set up and run **worker** program. It's supposed to have required binaries installed. Also, using systemd is recommended for best user experience, but it's not required. Almost all modern Linux distributions are using systemd now.
+Following text describes how to set up and run **worker** program. It's supposed to have required binaries installed. Also, using systemd is recommended for best user experience, but it's not required. Almost all modern Linux distributions are using systemd nowadays.
 
 ### Default worker configuration
 
@@ -151,7 +151,7 @@ Worker should have some default configuration which is applied to worker itself
 
 Mandatory items are bold, optional italic.
 
-- **worker-id** - unique identification of worker at one server. This id is used by _isolate_ sanbox on linux systems, so make sure to meet isolates requirements (default is number from 1 to 999).
+- **worker-id** - unique identification of worker at one server. This id is used by _isolate_ sanbox on linux systems, so make sure to meet isolate's requirements (default is number from 1 to 999).
 - **broker-uri** - URI of the broker (hostname, IP address, including port, ...)
 - _broker-ping-interval_ - time interval how often to send ping messages to broker. Used units are milliseconds.
 - _max-broker-liveness_ - specifies how many pings in a row can broker miss without making the worker dead.
@@ -165,13 +165,13 @@ Mandatory items are bold, optional italic.
     - _username_ - username for http authentication (if needed)
     - _password_ - password for http authentication (if needed)
 - _file-cache_ - configuration of caching feature
-    - _cache-dir_ - path to caching directory. Can be the same for mutltiple workers.
+    - _cache-dir_ - path to caching directory. Can be the same for multiple workers.
 - _logger_ - settings of logging capabilities
     - _file_ - path to the logging file with name without suffix. `/var/log/recodex/worker` item will produce `worker.log`, `worker.1.log`, ...
     - _level_ - level of logging, one of `off`, `emerg`, `alert`, `critical`, `err`, `warn`, `notice`, `info` and `debug`
     - _max-size_ - maximal size of log file before rotating
     - _rotations_ - number of rotation kept
-- _limits_ - default sandbox limits for this worker. All items are described in assignments section in job configuration description. If some limits are not set in job configuration, defaults from worker config will be used. Also, limits in job configuration cannot exceed limits from worker. In such case the worker's defaults will be set as the maximum for the job.
+- _limits_ - default sandbox limits for this worker. All items are described in assignments section in job configuration description. If some limits are not set in job configuration, defaults from worker config will be used. In such case the worker's defaults will be set as the maximum for the job. Also, limits in job configuration cannot exceed limits from worker.
 
 #### Example config file
 
@@ -271,11 +271,11 @@ Chapter by itself is filesystem handling. Isolate uses mount kernel namespace to
 
 #### Limit isolate boxes to particular cpu or memory node
 
-New feature in version 1.3 is possibility of limit Isolate box to one or more cpu or memory node. This functionality is provided by _cpusets_ kernel mechanism and is now integrated in isolate. It is allowed to set only `cpuset.cpus` and `cpuset.mems` which should be just fine for sandbox purposes. As kernel functionality further description can be found in manual page of _cpuset_ or in Linux documentation in section `linux/Documentation/cgroups/cpusets.txt`. As previously stated this settings can be applied for particular Isolate boxes and has to be written in Isolate configuration. Standard configuration path should be `/usr/local/etc/isolate` but it may depend on your installation process. Configuration of _cpuset_ in there is really simple and is described in example below.
+New feature in version 1.3 is possibility of limit Isolate box to one or more cpu or memory node. This functionality is provided by _cpusets_ kernel mechanism and is now integrated in isolate. It's allowed to set only `cpuset.cpus` and `cpuset.mems` which should be just fine for sandbox purposes. As kernel functionality further description can be found in manual page of _cpuset_ or in Linux documentation in section `linux/Documentation/cgroups/cpusets.txt`. As previously stated this settings can be applied for particular isolate boxes and has to be written in isolate configuration. Standard configuration path should be `/usr/local/etc/isolate` but it may depend on your installation process. Configuration of _cpuset_ in there is really simple and is described in example below.
 
 ```
-box0.cpus = 0  # assign processor ID 0 to isolate box with ID 0
+box0.cpus = 0  # assign processor with ID 0 to isolate box with ID 0
-box0.mems = 0  # assign memory node with id 0
+box0.mems = 0  # assign memory node with ID 0
 # if not set, linux by itself will decide where should
 # the sandboxed programs run at
 box2.cpus = 1-3  # assign range of processors to isolate box 2
@@ -297,11 +297,11 @@ WrapSharp is sandbox for programs in C# written also in C#. We have written it a
 
 Cleaner is integral part of worker which manages its cache folder, mainly deletes outdated files. Every cleaner instance maintains one cache folder, which can be used by multiple workers. This means on one server there can be numerous instances of workers with the same cache folder, but there should be only one cleaner.
 
-Cleaner is written in Python programming language and is used as simple script which just does its job and ends, so has to be cronned. For proper function of cleaner some suitable cronning interval has to be used. Its recommended to use 24 hour interval which should be sufficient enough.
+Cleaner is written in Python programming language and is used as simple script which just does its job and ends, so has to be cronned. For proper function of cleaner some suitable cronning interval has to be used. It's recommended to use 24 hour interval which should be sufficient enough.
 
 #### Last access timestamp
 
-There is a bit of catch with cleaner service, to work properly, server filesystem has to have enabled last access timestamp. Cleaner checks these stamps and based on them it decides if file will be deleted or not, simple write timestamp or created at timestamp are not enough to reflect real usage and need of particular file. Last access timestamp feature is a bit controversial (more on this subject can be found [here](https://en.wikipedia.org/wiki/Stat_%28system_call%29#Criticism_of_atime)) and its not by default enabled on conventional filesystems. In linux this can be solved by adding `strictatime` option to `fstab` file. On Windows following command has to be executed (as administrator) `fsutil behavior set disablelastaccess 0`.
+There is a bit of catch with cleaner service, to work properly, server filesystem has to have enabled last access timestamp. Cleaner checks these stamps and based on them it decides if file will be deleted or not, simple write timestamp or created at timestamp are not enough to reflect real usage and need of particular file. Last access timestamp feature is a bit controversial (more on this subject can be found [here](https://en.wikipedia.org/wiki/Stat_%28system_call%29#Criticism_of_atime)) and it's not by default enabled on conventional filesystems. In linux this can be solved by adding `strictatime` option to `fstab` file. On Windows following command has to be executed (as administrator) `fsutil behavior set disablelastaccess 0`.
 
 ### Installation