Beautifying many debug messages..

[collectd.git] / src / collectd.pod

diff --git a/src/collectd.pod b/src/collectd.pod
index aae4315..5a9f420 100644 (file)
--- a/src/collectd.pod
+++ b/src/collectd.pod
@@ -42,7 +42,7 @@ config-option.
 
 Don't fork to the background. I<collectd> will also B<not> close standard file
 descriptors, detach from the session nor write a pid file. This is mainly
-thought for 'supervisioning' init replacements such as I<runit>.
+thought for 'supervising' init replacements such as I<runit>.
 
 =item B<-h>
 
@@ -63,7 +63,7 @@ There are two big groups of plugins, B<input> and B<output> plugins:
 
 =item
 
-Input plugins are queried periodically. They somehow aquire the current value
+Input plugins are queried periodically. They somehow acquire the current value
 of whatever they where designed to work with and submit these values back to
 the daemon, i. e. they "dispatch" the values. As an example, the C<cpu plugin>
 reads the current cpu-counters of time spent in the various modes (user,
@@ -81,7 +81,7 @@ Of course not all plugins fit neatly into one of the two above categories. The
 C<network plugin>, for example, is able to send (i.E<nbsp>e. "write") B<and>
 receive (i.E<nbsp>e. "dispatch") values. Also, it opens a socket upon
 initialization and dispatches the values when it receives them and isn't
-triggered at the same time the input plugins are being read. You can think if
+triggered at the same time the input plugins are being read. You can think of
 the network receive part as working asynchronous if it helps.
 
 In addition to the above, there are "logging plugins". Right now those are the