path: root/doc
diff options
authorpsyc://loupsycedyglgamf.onion/~lynX <ircs://>2018-06-27 10:59:52 +0000
committerpsyc://loupsycedyglgamf.onion/~lynX <ircs://>1984-04-04 00:44:04 +0000
commit96d63458bc11fa18c7d7e334b6509ce6e0196890 (patch)
tree9d0a5e9b1e11b97c84a1048336fa19ba730f3450 /doc
parent62fa707cf1568a487323f904061a27dcfb0642fa (diff)
-docs: the world ain't all male II
Diffstat (limited to 'doc')
4 files changed, 12 insertions, 12 deletions
diff --git a/doc/documentation/chapters/developer.texi b/doc/documentation/chapters/developer.texi
index 4167c3d62..1f74a8163 100644
--- a/doc/documentation/chapters/developer.texi
+++ b/doc/documentation/chapters/developer.texi
@@ -4382,7 +4382,7 @@ If you encounter problems regarding the SDP server (like the SDP server is
down) you should check out if the D-Bus daemon is running correctly and to
see if the Bluetooth daemon started correctly(use @code{bluetoothd} tool).
Also, sometimes the SDP service could work but somehow the device couldn't
-register his service. Use @code{sdptool browse [dev-address]} to see if
+register its service. Use @code{sdptool browse [dev-address]} to see if
the service is registered. There should be a service with the name of the
interface and GNUnet as provider.
@@ -5453,7 +5453,7 @@ calls: @code{GNUNET_NSE_connect} and @code{GNUNET_NSE_disconnect}.
The connect call gets a callback function as a parameter and this function
is called each time the network agrees on an estimate. This usually is
once per round, with some exceptions: if the closest peer has a late
-local clock and starts spreading his ID after everyone else agreed on a
+local clock and starts spreading its ID after everyone else agreed on a
value, the callback might be activated twice in a round, the second value
being always bigger than the first. The default round time is set to
1 hour.
@@ -5579,7 +5579,7 @@ is what we are flooding the network with right now.
At the beginning of each round the peer does the following:
@itemize @bullet
-@item calculates his own distance to the target value
+@item calculates its own distance to the target value
@item creates, signs and stores the message for the current round (unless
it has a better message in the "next round" slot which came early in the
previous round)
@@ -6215,8 +6215,8 @@ So a client has first to retrieve records, merge with existing records
and then store the result.
To perform a lookup operation, the client uses the
-@code{GNUNET_NAMESTORE_records_store} function. Here he has to pass the
-namestore handle, the private key of the zone and the label. He also has
+@code{GNUNET_NAMESTORE_records_store} function. Here it has to pass the
+namestore handle, the private key of the zone and the label. It also has
to provide a callback function which will be called with the result of
the lookup operation:
the zone for the records, the label, and the records including the
@@ -6239,7 +6239,7 @@ by NAMESTORE.
Here a client uses the @code{GNUNET_NAMESTORE_zone_iteration_start}
function and passes the namestore handle, the zone to iterate over and a
callback function to call with the result.
-If the client wants to iterate over all the, he passes NULL for the zone.
+If the client wants to iterate over all the WHAT!? FIXME, it passes NULL for the zone.
A @code{GNUNET_NAMESTORE_ZoneIterator} handle is returned to be used to
continue iteration.
@@ -6935,7 +6935,7 @@ number of iterations).
The receiver of the message removes all elements from its local set that
do not pass the Bloom filter test.
It then checks if the set size of the sender and the XOR over the keys
-match what is left of his own set. If they do, he sends a
+match what is left of its own set. If they do, it sends a
that the latest set is the final result.
Otherwise, the receiver starts another Bloom filter exchange, except
@@ -8239,7 +8239,7 @@ When a revocation is performed, the revocation is first of all
disseminated by flooding the overlay network.
The goal is to reach every peer, so that when a peer needs to check if a
key has been revoked, this will be purely a local operation where the
-peer looks at his local revocation list. Flooding the network is also the
+peer looks at its local revocation list. Flooding the network is also the
most robust form of key revocation --- an adversary would have to control
a separator of the overlay graph to restrict the propagation of the
revocation message. Flooding is also very easy to implement --- peers that
diff --git a/doc/documentation/chapters/user.texi b/doc/documentation/chapters/user.texi
index 4a82295c4..9c9bd8df8 100644
--- a/doc/documentation/chapters/user.texi
+++ b/doc/documentation/chapters/user.texi
@@ -2264,7 +2264,7 @@ the configuration:
If you operate a peer permanently connected to GNUnet you can configure
your peer to act as a hostlist server, providing other peers the list of
-peers known to him.
+peers known to it.
Your server can act as a bootstrap server and peers needing to obtain a
list of peers can contact it to download this list.
@@ -2883,7 +2883,7 @@ iwconfig wlan0 channel 1
@subsection Configuring HTTP(S) reverse proxy functionality using Apache or nginx
The HTTP plugin supports data transfer using reverse proxies. A reverse
-proxy forwards the HTTP request he receives with a certain URL to another
+proxy forwards the HTTP request it receives with a certain URL to another
webserver, here a GNUnet peer.
So if you have a running Apache or nginx webserver you can configure it to
diff --git a/doc/man/gnunet-revocation.1 b/doc/man/gnunet-revocation.1
index 017b019fd..b963b2dc0 100644
--- a/doc/man/gnunet-revocation.1
+++ b/doc/man/gnunet-revocation.1
@@ -15,7 +15,7 @@ instantly revoke a key and to use a pre-generated revocation
certificate to revoke a key. Upon successful revocation, all peers
will be informed about the invalidity of the key. As this is an
expensive operation, GNUnet requires the issuer of the revocation to
-perform an expensive proof-of-work computation before he will be
+perform an expensive proof-of-work computation before they will be
allowed to perform the revocation. gnunet\-revocation will perform
this computation. The computation can be performed ahead of time,
with the resulting revocation certificate being stored in a file for
diff --git a/doc/release_policy.rfc.txt b/doc/release_policy.rfc.txt
index fd4118742..b3d72bac4 100644
--- a/doc/release_policy.rfc.txt
+++ b/doc/release_policy.rfc.txt
@@ -117,7 +117,7 @@ platforms. It also doubt it will give you the recognition you crave.
More importantly, what you describe is already happening, and
partially has contributed to the problems. Bart kept his own CADET
hacks in his personal branch for years, hence without much feedback or
-review. The SecuShare team kept their patches in their own branch,
+review. The secushare team kept their patches in their own branch,
hence revealing interesting failure modes when it was finally merged.
Martin kept some of his ABE-logic in his own branch (that one was
merged without me noticing major problems). Anyway, what you propose