Add comments

tutorial/3/cgroups.md

@@ -180,7 +180,8 @@ Liste non exhaustive de données à monitorer :
 * trafic réseau généré ;
 * ...
 
-<https://www.kernel.org/doc/Documentation/cgroup-v1/>
+Tous les cgroups existants dans le dernier noyau publié ont leur documentation
+accessible ici : <https://www.kernel.org/doc/Documentation/cgroup-v1/>
 
 
 ### Permettre à l'utilisateur de monitorer des processus
@@ -202,6 +203,9 @@ privilèges particuliers.
 
 ## Pour aller plus loin
 
+Pour tout connaître en détails, [la série d'articles de Neil Brown sur les
+Control groups](https://lwn.net/Articles/604609/) est excellente !
+
 Depuis les noyaux 4.5, il est possible d'utiliser la nouvelle version du
 pseudo système de fichiers des *CGroup*s. Le principal changement vient du
 regroupement au sein d'une seule hiérarchie des différents *CGroup*s que l'on
@@ -210,6 +214,3 @@ avait dans la v1. Davantage d'informations sont disponibles :
 * [Understanding the new control groups API](https://lwn.net/Articles/679786/)
   ;
 * [Kernel Document about Control Group v2](https://www.kernel.org/doc/Documentation/cgroup-v2.txt).
-
-Pour tout connaître en détails, [la série d'articles de Neil Brown sur les
-Control groups](https://lwn.net/Articles/604609/) est excellente !

tutorial/3/chroot.md

@@ -4,7 +4,8 @@ L'isolation ... du pauvre
 =========================
 
 Depuis les premières versions d'Unix, il est possible de changer le répertoire
-vu comme étant la racine du système de fichiers.
+vu comme étant la racine du système de fichiers. En anglais : *change root*:
+`chroot`.
 
 
 ## Mise en place de l'environnement

tutorial/3/pseudofs.md

@@ -6,7 +6,7 @@ Pseudos systèmes de fichiers
 ## Rappels sur les points de montage
 
 Les systèmes Unix définissent le système de fichiers comme étant un arbre
-unique partant d'une racine et où l'on peut placer au sein de son arborescence
+unique partant d'une racine[1] et où l'on peut placer au sein de son arborescence
 des points de montage. Ainsi, l'utilisateur définit généralement deux points de
 montage :
 
@@ -138,3 +138,5 @@ l'OOM-killer alors que le serveur applicatif utilise largement plus de mémoire
 2. Pourquoi est-ce le serveur de base de données qui est principalement tiré au
    sort pour être tué en cas de manque de mémoire plutôt que le serveur
    applicatif qui occupe pourtant bien plus de mémoire ?
+
+[1]: Consultez <https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard> pour plus de détails sur l'arboresence.