Re: [LCFC] po4a://manpages-fr/vfork.2.po 5f 4u
Bonjour,
correction de l’erreur fatale de construction et suggestions.
Amicalement.
--
Jean-Paul
--- vfork.2.po.orig 2021-08-17 10:25:50.479727439 +0200
+++ vfork.2.po 2021-08-17 10:58:37.749186699 +0200
@@ -20,7 +20,7 @@
msgstr ""
"Project-Id-Version: perkamon\n"
"POT-Creation-Date: 2021-06-26 14:38+0200\n"
-"PO-Revision-Date: 2021-08-17 10:25+0200\n"
+"PO-Revision-Date: 2021-08-17 10:58+0200\n"
"Last-Translator: Jean-Pierre Giraud <jean-pierregiraud@neuf.fr>\n"
"Language-Team: French <debian-l10n-french@lists.debian.org>\n"
"Language: fr\n"
@@ -225,7 +225,7 @@
"Comme avec B<fork>(2), le processus enfant créé par B<vfork>() hérite des "
"copies de plusieurs attributs du processus appelant (par exemple les "
"descripteurs de fichiers, les dispositions des signaux et le répertoire de "
-"travail actuel)\\ ; l'appel B<vfork>() diffère seulement par le traitement "
+"travail actuel)\\ ; l'appel B<vfork>() diffère seulement par le traitement "
"de l'espace d'adressage virtuel, comme décrit ci-dessus."
#. type: Plain text
@@ -267,9 +267,9 @@
"Sous Linux, B<fork>(2) est implémenté en utilisant un mécanisme de copie en "
"écriture, ainsi ses seuls coûts sont le temps et la mémoire nécessaire pour "
"dupliquer la table des pages mémoire du processus parent, et créer une "
-"structure de tâche pour l'enfant. Toutefois, jadis B<fork>(2) nécessitait "
-"malheureusement une copie complète de l'espace d'adresse du parent, souvent "
-"inutile, car un appel B<exec>(3) est souvent réalisé immédiatement par "
+"seule structure de tâche pour l'enfant. Toutefois, jadis B<fork>(2) nécessitait "
+"malheureusement une copie complète de l'espace de données du parent, souvent "
+"inutilement, car un appel B<exec>(3) est souvent réalisé immédiatement par "
"l'enfant. Pour améliorer les performances, BSD a introduit un appel système "
"B<vfork>() qui ne copie pas l'espace d'adressage du parent, mais emprunte au "
"parent son espace d'adressage et son fil de contrôle jusqu'à un appel à "
@@ -307,7 +307,7 @@
"remaining blocked until the child either terminates or calls B<execve>(2), "
"and cannot rely on any specific behavior with respect to shared memory."
msgstr ""
-"Les exigences que les standards apportent sur B<vfork>() sont plus relâchées "
+"Les exigences que les normes apportent sur B<vfork>() sont moindres "
"que celles sur B<fork>(2), ainsi il est possible d'avoir une implémentation "
"conforme où les deux appels sont synonymes. En particulier, un programmeur "
"ne doit pas s'appuyer sur le fait que le parent reste bloqué jusqu'à ce que "
@@ -338,8 +338,8 @@
"architecturale, et la page de manuel de 4.2BSD indique que «\\ cet appel "
"système sera supprimé quand des mécanismes de partage appropriés seront "
"implémentés. Il ne faut pas essayer de tirer profit du partage mémoire "
-"induit par B<vfork>(), car dans ce cas il sera rendu synonyme de "
-"B<fork>(2)\\ ». Cependant, même si le matériel de gestion mémoire matériel a "
+"induit par B<vfork>(), car dans ce cas il serait rendu synonyme de "
+"B<fork>(2)\\ ». Cependant, même si le matériel de gestion mémoire moderne a "
"diminué la différence de performances entre B<fork>(2) et B<vfork>(), il "
"existe diverses raisons pour lesquelles Linux et d'autres systèmes ont "
"conservé B<vfork>()\\ :"
@@ -397,14 +397,14 @@
"overcommitting memory with the risk that a process is terminated by the out-"
"of-memory (OOM) killer."
msgstr ""
-"Sur les systèmes où la mémoire est contrainte, B<vfork> évite le besoin "
+"Sur les systèmes où la mémoire est restreinte, B<vfork> évite le besoin "
"d'allouer de la mémoire temporairement (voir la description de I</proc/sys/"
"vm/overcommit_memory> dans B<proc>(5)) afin d'exécuter un nouveau programme. "
"Cela peut être particulièrement bénéfique lorsqu'un grand processus parent "
"souhaite exécuter un petit programme d'assistance dans un processus enfant. "
"Par contraste, l'utilisation de B<fork>(2) dans ce scénario nécessite soit "
"l'allocation d'une quantité de mémoire égale à la taille du processus parent "
-"(la gestion stricte du dépassement est en cours) soit un dépassement de "
+"(si la gestion stricte du dépassement est en cours) soit un dépassement de "
"mémoire avec le risque qu'un processus soit terminé par la mise à mort sur "
"mémoire saturée (OOM killer)."
@@ -429,10 +429,10 @@
"file descriptors would not be visible)."
msgstr ""
"Le processus enfant devrait veiller à ne pas modifier la mémoire d'une "
-"manière inattendue, dans la mesure où les modification seront vues par le "
+"manière inattendue, dans la mesure où les modifications seront vues par le "
"processus parent une fois que l'enfant s'est achevé ou exécute un autre "
"programme. À cet égard, les gestionnaires de signaux peuvent être "
-"particulièrement problématiques : si un gestionnaire de signaux qui est "
+"particulièrement problématiques : si un gestionnaire de signal qui est "
"invoqué dans l'enfant d'un B<vfork>() modifie la mémoire, ces modifications "
"peuvent aboutir à une inconsistance de l'état du processus du point de vue "
"du processus parent (par exemple, les modifications de la mémoire pourraient "
@@ -461,12 +461,12 @@
"appelant est suspendu jusqu'à ce que l'enfant s'achève ou exécute un nouveau "
"programme. Cela signifie que l'enfant partage un espace d'adresses avec un "
"autre code en cours d'exécution. Cela peut être dangereux si un autre thread "
-"dans le processus parent modifie son identifiant (avec B<setuid>(2) ou une "
+"dans le processus parent modifie ses droits (avec B<setuid>(2) ou une "
"autre commande similaire), dans la mesure où il y a alors deux processus "
"avec différents niveaux de privilèges exécutés dans le même espace "
"d'adresses. Comme exemple de risque, imaginez qu'un programme multithreadé "
"exécuté en tant que superutilisateur crée un enfant avec B<vfork>(). Après "
-"le B<vfork>(), un thread dans le processus parent abaisse le processus à un "
+"le B<vfork>(), un thread dans le processus parent transfère le processus à un "
"utilisateur non privilégié afin d'exécuter du code non sûr (par exemple, "
"peut-être au moyen d'un greffon ouvert avec B<dlopen>(3)). Dans ce cas, des "
"attaques sont possibles où le processus parent utilise B<mmap>(2) pour "
@@ -539,8 +539,7 @@
"html> E<.UE >). Sous Linux, il a été l'équivalent de B<fork>(2) jusqu'au "
"noyau 2.2.0-pre-6. Depuis le noyau 2.2.0-pre-9 (sur i386, un peu plus tard "
"sur d'autres architectures), il s'agit d'un appel système indépendant. "
-"La prise en charge dans la bibliothèque a été introduite dans la
-glibc 2.0.112."
+"La prise en charge dans la bibliothèque a été introduite dans la glibc 2.0.112."
#. type: SH
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
Reply to: