doc/documentation/chapters/developer.texi: GNU -> GNU/Linux

(in parts where it is technically correct and not just the kernel is referenced).

diff --git a/doc/documentation/chapters/developer.texi b/doc/documentation/chapters/developer.texi
index fa90942689e9ac6e13c811b6fa9aa8ac30d6ab8b..f3f12405bd0d7357d0a3b2f98a273a752d9865a2 100644 (file)
--- a/doc/documentation/chapters/developer.texi
+++ b/doc/documentation/chapters/developer.texi
@@ -3881,9 +3881,11 @@ ask on the IRC channel.
 @subsection What do I need to use the Bluetooth plugin transport?
 @c %**end of header
 
-If you are a Linux user and you want to use the Bluetooth transport plugin
-you should install the BlueZ development libraries (if they aren't already
-installed). For instructions about how to install the libraries you should
+If you are a GNU/Linux user and you want to use the Bluetooth
+transport plugin you should install the
+@command{BlueZ development libraries} (if they aren't already
+installed).
+For instructions about how to install the libraries you should
 check out the BlueZ site
 (@uref{http://www.bluez.org/, http://www.bluez.org}). If you don't know if
 you have the necesarry libraries, don't worry, just run the GNUnet
@@ -3910,7 +3912,7 @@ The Bluetooth transport plugin uses virtually the same code as the WLAN
 plugin and only the helper binary is different. The helper takes a single
 argument, which represents the interface name and is specified in the
 configuration file. Here are the basic steps that are followed by the
-helper binary used on Linux:
+helper binary used on GNU/Linux:
 
 @itemize @bullet
 @item it verifies if the name corresponds to a Bluetooth interface name
@@ -3975,8 +3977,9 @@ the device and to send some particular commands to it.
 @subsection How do I configure my peer2?
 @c %**end of header
 
-On Linux, you just have to be sure that the interface name corresponds to
-the one that you want to use. Use the @code{hciconfig} tool to check that.
+On GNU/Linux, you just have to be sure that the interface name
+corresponds to the one that you want to use.
+Use the @code{hciconfig} tool to check that.
 By default it is set to hci0 but you can change it.
 
 A basic configuration looks like this:
@@ -4008,8 +4011,8 @@ transport service.
 @subsection How can I test it?
 @c %**end of header
 
-If you have two Bluetooth devices on the same machine which use Linux you
-must:
+If you have two Bluetooth devices on the same machine and you are using
+GNU/Linux you must:
 
 @itemize @bullet
 
@@ -4065,7 +4068,7 @@ plugin: it acceses the interface and then it forwards traffic in both
 directions between the Bluetooth interface and stdin/stdout of the
 process involved.
 
-The Bluetooth plugin transport could be used both on Linux and Windows
+The Bluetooth plugin transport could be used both on GNU/Linux and Windows
 platforms.
 
 @itemize @bullet
@@ -4089,8 +4092,9 @@ platforms.
 @subsubsection Linux functionality
 @c %**end of header
 
-In order to implement the plugin functionality on Linux I used the BlueZ
-stack. For the communication with the other devices I used the RFCOMM
+In order to implement the plugin functionality on GNU/Linux I
+used the BlueZ stack.
+For the communication with the other devices I used the RFCOMM
 protocol. Also I used the HCI protocol to gain some control over the
 device. The helper binary takes a single argument (the name of the
 Bluetooth interface) and is separated in two stages:
@@ -4245,7 +4249,7 @@ but you should keep in mind that you should have the latest updates
 (especially the @emph{ws2bth} header).
 
 Besides the fact that it uses the Windows Sockets, the Windows
-implemenation follows the same principles as the Linux one:
+implemenation follows the same principles as the GNU/Linux one:
 
 @itemize @bullet
 @item It has a initalization part where it initializes the
@@ -4265,17 +4269,19 @@ In order to register the service I used the @emph{WSASetService} function
 and I generated the @emph{Universally Unique Identifier} with the
 @emph{guidgen.exe} Windows's tool.
 
-In the loop section the only difference from the Linux implementation is
-that I used the GNUNET_NETWORK library for functions like @emph{accept},
-@emph{bind}, @emph{connect} or @emph{select}. I decided to use the
-GNUNET_NETWORK library because I also needed to interact with the STDIN
-and STDOUT handles and on Windows the select function is only defined for
-sockets, and it will not work for arbitrary file handles.
-
-Another difference between Linux and Windows implementation is that in
-Linux, the Bluetooth address is represented in 48 bits while in Windows is
-represented in 64 bits. Therefore I had to do some changes on
-@emph{plugin_transport_wlan} header.
+In the loop section the only difference from the GNU/Linux implementation
+is that I used the @code{GNUNET_NETWORK} library for
+functions like @emph{accept}, @emph{bind}, @emph{connect} or
+@emph{select}. I decided to use the
+@code{GNUNET_NETWORK} library because I also needed to interact
+with the STDIN and STDOUT handles and on Windows
+the select function is only defined for sockets,
+and it will not work for arbitrary file handles.
+
+Another difference between GNU/Linux and Windows implementation is that in
+GNU/Linux, the Bluetooth address is represented in 48 bits
+while in Windows is represented in 64 bits.
+Therefore I had to do some changes on @emph{plugin_transport_wlan} header.
 
 Also, currently on Windows the Bluetooth plugin doesn't have support for
 broadcast messages. When it receives a broadcast message it will skip it.