NiKo , dans le message <4ecd4c08$0$24216$, a
écrit :Pas besoin, il suffit de lire le code, et voila ce qu'elle fait :
177 fd = open (fname, oflag | O_NOFOLLOW, mode);
Ah ben zut, en fait shm_open ferait en fait un vulgaire "open" ...
Je n'ai pas prétendu le contraire. Tu noteras cependant qu'elle ne cherche
absolument pas à se prémunir contre l'existence de fichiers de même nom (je
te laisse le soin de chercher dans la doc d'open comment elle aurait dû
faire).
1) Tu ne sais rien de mon niveau.
Ça fait quelques années que je lis des messages de toi ici et sur fcold.
2) Excepté que la GLIBC utilise de préférence le répertoire /dev/shm
pour ses objets mémoire partagés, je ne vois pas dans le code le moindre
avertissement signalant qu'il ne faut absolument pas qu'un utilisateur
place des fichiers dans /dev/shm !
Parce que tu t'attends à trouver des avertissements destinés aux
utilisateurs dans le code source d'une bibliothèque ?
3) Sont vraiment nuls les développeurs du noyau et les développeurs
GNU/Linux en général ! Laisser un accès en écriture sur un répertoire à
un utilisateur standard du système alors que Monsieur Nicolas George
SAIT qu'il ne faut absolument rien mettre dans ce répertoire ...
Je n'ai pas dit ça, apprends à lire.
4) Et comment fait un utilisateur pour se créer une 'instance' de tmpfs
? Comment ? J'entends au fond de la salle qu'il faut qu'il soit root ?
Il ne fait pas. L'utilisateur qui veut créer des fichiers et répertoires
temporaires les met dans /tmp, c'est fait pour ça. S'il est attentif, il
peut éventuellement remarquer que /tmp est une instance de tmpfs et se
réjouir d'avoir un administrateur compétent, mais ça s'arrête là.
5) Il serait temps que tu comprennes la philosophie Unix ...
Là, tu es franchement ridicule.
NiKo , dans le message <4ecd4c08$0$24216$426a34cc@news.free.fr>, a
écrit :
Pas besoin, il suffit de lire le code, et voila ce qu'elle fait :
177 fd = open (fname, oflag | O_NOFOLLOW, mode);
Ah ben zut, en fait shm_open ferait en fait un vulgaire "open" ...
Je n'ai pas prétendu le contraire. Tu noteras cependant qu'elle ne cherche
absolument pas à se prémunir contre l'existence de fichiers de même nom (je
te laisse le soin de chercher dans la doc d'open comment elle aurait dû
faire).
1) Tu ne sais rien de mon niveau.
Ça fait quelques années que je lis des messages de toi ici et sur fcold.
2) Excepté que la GLIBC utilise de préférence le répertoire /dev/shm
pour ses objets mémoire partagés, je ne vois pas dans le code le moindre
avertissement signalant qu'il ne faut absolument pas qu'un utilisateur
place des fichiers dans /dev/shm !
Parce que tu t'attends à trouver des avertissements destinés aux
utilisateurs dans le code source d'une bibliothèque ?
3) Sont vraiment nuls les développeurs du noyau et les développeurs
GNU/Linux en général ! Laisser un accès en écriture sur un répertoire à
un utilisateur standard du système alors que Monsieur Nicolas George
SAIT qu'il ne faut absolument rien mettre dans ce répertoire ...
Je n'ai pas dit ça, apprends à lire.
4) Et comment fait un utilisateur pour se créer une 'instance' de tmpfs
? Comment ? J'entends au fond de la salle qu'il faut qu'il soit root ?
Il ne fait pas. L'utilisateur qui veut créer des fichiers et répertoires
temporaires les met dans /tmp, c'est fait pour ça. S'il est attentif, il
peut éventuellement remarquer que /tmp est une instance de tmpfs et se
réjouir d'avoir un administrateur compétent, mais ça s'arrête là.
5) Il serait temps que tu comprennes la philosophie Unix ...
Là, tu es franchement ridicule.
NiKo , dans le message <4ecd4c08$0$24216$, a
écrit :Pas besoin, il suffit de lire le code, et voila ce qu'elle fait :
177 fd = open (fname, oflag | O_NOFOLLOW, mode);
Ah ben zut, en fait shm_open ferait en fait un vulgaire "open" ...
Je n'ai pas prétendu le contraire. Tu noteras cependant qu'elle ne cherche
absolument pas à se prémunir contre l'existence de fichiers de même nom (je
te laisse le soin de chercher dans la doc d'open comment elle aurait dû
faire).
1) Tu ne sais rien de mon niveau.
Ça fait quelques années que je lis des messages de toi ici et sur fcold.
2) Excepté que la GLIBC utilise de préférence le répertoire /dev/shm
pour ses objets mémoire partagés, je ne vois pas dans le code le moindre
avertissement signalant qu'il ne faut absolument pas qu'un utilisateur
place des fichiers dans /dev/shm !
Parce que tu t'attends à trouver des avertissements destinés aux
utilisateurs dans le code source d'une bibliothèque ?
3) Sont vraiment nuls les développeurs du noyau et les développeurs
GNU/Linux en général ! Laisser un accès en écriture sur un répertoire à
un utilisateur standard du système alors que Monsieur Nicolas George
SAIT qu'il ne faut absolument rien mettre dans ce répertoire ...
Je n'ai pas dit ça, apprends à lire.
4) Et comment fait un utilisateur pour se créer une 'instance' de tmpfs
? Comment ? J'entends au fond de la salle qu'il faut qu'il soit root ?
Il ne fait pas. L'utilisateur qui veut créer des fichiers et répertoires
temporaires les met dans /tmp, c'est fait pour ça. S'il est attentif, il
peut éventuellement remarquer que /tmp est une instance de tmpfs et se
réjouir d'avoir un administrateur compétent, mais ça s'arrête là.
5) Il serait temps que tu comprennes la philosophie Unix ...
Là, tu es franchement ridicule.
Soit open le fait, et dans ce cas ce serait redondant de le faire aussi
dans shm_open. Soit open ne le fait pas et c'est au développeur de
l'application de le faire. Bref, rien qui abonde dans ton sens en fait.
Non, je m'attendais simplement à ce que tu me pointes une DOC qui
stipulerais qu'il est idiot qu'un utilisateur crée des fichiers dans
/dev/shm !
Dans ce cas, pourquoi parles tu de 'créer ta propre instance dans un
répertoire différent', si je ne peux pas créer ma propre instance ?
Et comme on peut voir dans le code, si tmpfs n'est pas monté sur
/dev/shm, la glibc utilise le premier point de montage de tmpfs qu'elle
trouve. Si ce premier point de montage est /tmp, tu préconises alors de
faire quoi dans le cas d'un utilisateur qui voudrait alors créer des
fichiers dans /tmp ?
Soit open le fait, et dans ce cas ce serait redondant de le faire aussi
dans shm_open. Soit open ne le fait pas et c'est au développeur de
l'application de le faire. Bref, rien qui abonde dans ton sens en fait.
Non, je m'attendais simplement à ce que tu me pointes une DOC qui
stipulerais qu'il est idiot qu'un utilisateur crée des fichiers dans
/dev/shm !
Dans ce cas, pourquoi parles tu de 'créer ta propre instance dans un
répertoire différent', si je ne peux pas créer ma propre instance ?
Et comme on peut voir dans le code, si tmpfs n'est pas monté sur
/dev/shm, la glibc utilise le premier point de montage de tmpfs qu'elle
trouve. Si ce premier point de montage est /tmp, tu préconises alors de
faire quoi dans le cas d'un utilisateur qui voudrait alors créer des
fichiers dans /tmp ?
Soit open le fait, et dans ce cas ce serait redondant de le faire aussi
dans shm_open. Soit open ne le fait pas et c'est au développeur de
l'application de le faire. Bref, rien qui abonde dans ton sens en fait.
Non, je m'attendais simplement à ce que tu me pointes une DOC qui
stipulerais qu'il est idiot qu'un utilisateur crée des fichiers dans
/dev/shm !
Dans ce cas, pourquoi parles tu de 'créer ta propre instance dans un
répertoire différent', si je ne peux pas créer ma propre instance ?
Et comme on peut voir dans le code, si tmpfs n'est pas monté sur
/dev/shm, la glibc utilise le premier point de montage de tmpfs qu'elle
trouve. Si ce premier point de montage est /tmp, tu préconises alors de
faire quoi dans le cas d'un utilisateur qui voudrait alors créer des
fichiers dans /tmp ?
NiKo , dans le message <4ecd5e61$0$24228$, a
écrit :Soit open le fait, et dans ce cas ce serait redondant de le faire aussi
dans shm_open. Soit open ne le fait pas et c'est au développeur de
l'application de le faire. Bref, rien qui abonde dans ton sens en fait.
Du pur n'importe quoi, il n'y a rien à sauver dans ce paragraphe.
Non, je m'attendais simplement à ce que tu me pointes une DOC qui
stipulerais qu'il est idiot qu'un utilisateur crée des fichiers dans
/dev/shm !
Tu n'en trouveras pas plus que de doc qui t'explique qu'il est idiot de
modifier ~/.mozilla/firefox/*/places.sqlite avec un éditeur de texte ou de
créer n'importe quel fichier dans ~/.fontconfig ou /var/lock : parce que
justement, c'est tellement idiot qu'on ne s'imagine pas que quelqu'un
pourrait en avoir l'idée.
Dans ce cas, pourquoi parles tu de 'créer ta propre instance dans un
répertoire différent', si je ne peux pas créer ma propre instance ?
Tu peux le faire en demandant à l'administrateur s'il ne l'a pas déjà fait.
On tourne en rond, encore une fois.
Et comme on peut voir dans le code, si tmpfs n'est pas monté sur
/dev/shm, la glibc utilise le premier point de montage de tmpfs qu'elle
trouve. Si ce premier point de montage est /tmp, tu préconises alors de
faire quoi dans le cas d'un utilisateur qui voudrait alors créer des
fichiers dans /tmp ?
Le fonctionnement normal du système est d'avoir /dev/shm pour la libc et
/tmp pour les utilisateurs. Si /dev/shm n'existe pas ou n'est pas monté, on
est déjà dans une situation anormale. Le comportement d'un logiciel ou une
bibliothèque dans une situation anormale ne peut pas servir à justifier
quelque chose en situation normale.
NiKo , dans le message <4ecd5e61$0$24228$426a34cc@news.free.fr>, a
écrit :
Soit open le fait, et dans ce cas ce serait redondant de le faire aussi
dans shm_open. Soit open ne le fait pas et c'est au développeur de
l'application de le faire. Bref, rien qui abonde dans ton sens en fait.
Du pur n'importe quoi, il n'y a rien à sauver dans ce paragraphe.
Non, je m'attendais simplement à ce que tu me pointes une DOC qui
stipulerais qu'il est idiot qu'un utilisateur crée des fichiers dans
/dev/shm !
Tu n'en trouveras pas plus que de doc qui t'explique qu'il est idiot de
modifier ~/.mozilla/firefox/*/places.sqlite avec un éditeur de texte ou de
créer n'importe quel fichier dans ~/.fontconfig ou /var/lock : parce que
justement, c'est tellement idiot qu'on ne s'imagine pas que quelqu'un
pourrait en avoir l'idée.
Dans ce cas, pourquoi parles tu de 'créer ta propre instance dans un
répertoire différent', si je ne peux pas créer ma propre instance ?
Tu peux le faire en demandant à l'administrateur s'il ne l'a pas déjà fait.
On tourne en rond, encore une fois.
Et comme on peut voir dans le code, si tmpfs n'est pas monté sur
/dev/shm, la glibc utilise le premier point de montage de tmpfs qu'elle
trouve. Si ce premier point de montage est /tmp, tu préconises alors de
faire quoi dans le cas d'un utilisateur qui voudrait alors créer des
fichiers dans /tmp ?
Le fonctionnement normal du système est d'avoir /dev/shm pour la libc et
/tmp pour les utilisateurs. Si /dev/shm n'existe pas ou n'est pas monté, on
est déjà dans une situation anormale. Le comportement d'un logiciel ou une
bibliothèque dans une situation anormale ne peut pas servir à justifier
quelque chose en situation normale.
NiKo , dans le message <4ecd5e61$0$24228$, a
écrit :Soit open le fait, et dans ce cas ce serait redondant de le faire aussi
dans shm_open. Soit open ne le fait pas et c'est au développeur de
l'application de le faire. Bref, rien qui abonde dans ton sens en fait.
Du pur n'importe quoi, il n'y a rien à sauver dans ce paragraphe.
Non, je m'attendais simplement à ce que tu me pointes une DOC qui
stipulerais qu'il est idiot qu'un utilisateur crée des fichiers dans
/dev/shm !
Tu n'en trouveras pas plus que de doc qui t'explique qu'il est idiot de
modifier ~/.mozilla/firefox/*/places.sqlite avec un éditeur de texte ou de
créer n'importe quel fichier dans ~/.fontconfig ou /var/lock : parce que
justement, c'est tellement idiot qu'on ne s'imagine pas que quelqu'un
pourrait en avoir l'idée.
Dans ce cas, pourquoi parles tu de 'créer ta propre instance dans un
répertoire différent', si je ne peux pas créer ma propre instance ?
Tu peux le faire en demandant à l'administrateur s'il ne l'a pas déjà fait.
On tourne en rond, encore une fois.
Et comme on peut voir dans le code, si tmpfs n'est pas monté sur
/dev/shm, la glibc utilise le premier point de montage de tmpfs qu'elle
trouve. Si ce premier point de montage est /tmp, tu préconises alors de
faire quoi dans le cas d'un utilisateur qui voudrait alors créer des
fichiers dans /tmp ?
Le fonctionnement normal du système est d'avoir /dev/shm pour la libc et
/tmp pour les utilisateurs. Si /dev/shm n'existe pas ou n'est pas monté, on
est déjà dans une situation anormale. Le comportement d'un logiciel ou une
bibliothèque dans une situation anormale ne peut pas servir à justifier
quelque chose en situation normale.
Quelle bande de bras cassés tous ces gars qui se servent de /dev/shm !
<https://wiki.archlinux.org/index.php/dev/shm>
<http://projects.gentoo-fr.org/projects/gentoo-fr/wiki/Tmpfs>
[... On en trouve à la pelle des choses qui utilisent /dev/shm ...]
Tu devrais les contacter en urgence !
Non
Le fonctionnement normal d'une application qui détecte un truc anormal
n'est pas de faire une bidouille pour aller bosser dans un autre
répertoire.
Quelle bande de bras cassés tous ces gars qui se servent de /dev/shm !
<https://wiki.archlinux.org/index.php/dev/shm>
<http://projects.gentoo-fr.org/projects/gentoo-fr/wiki/Tmpfs>
[... On en trouve à la pelle des choses qui utilisent /dev/shm ...]
Tu devrais les contacter en urgence !
Non
Le fonctionnement normal d'une application qui détecte un truc anormal
n'est pas de faire une bidouille pour aller bosser dans un autre
répertoire.
Quelle bande de bras cassés tous ces gars qui se servent de /dev/shm !
<https://wiki.archlinux.org/index.php/dev/shm>
<http://projects.gentoo-fr.org/projects/gentoo-fr/wiki/Tmpfs>
[... On en trouve à la pelle des choses qui utilisent /dev/shm ...]
Tu devrais les contacter en urgence !
Non
Le fonctionnement normal d'une application qui détecte un truc anormal
n'est pas de faire une bidouille pour aller bosser dans un autre
répertoire.
NiKo , dans le message <4ecd6966$0$27879$, a
écrit :Quelle bande de bras cassés tous ces gars qui se servent de /dev/shm !
<https://wiki.archlinux.org/index.php/dev/shm>
« There is currently no text in this page. »
Super, ta référence !
<http://projects.gentoo-fr.org/projects/gentoo-fr/wiki/Tmpfs>
Là, clairement bras cassé. Allez, les plus flagrantes.
* « Je ne saurais trop vous conseillez », « tmpfs est trés simple à utliser
et peux »... no comment.
* Monter /tmp en noexec : merci pour les ./configure qui y font des tests de
compilation et d'exécution.
[... On en trouve à la pelle des choses qui utilisent /dev/shm ...]
On trouve énormément d'idioties sur le web, en effet.
Tu devrais les contacter en urgence !
Je l'ai déjà dit, je ne vais pas prendre mon temps à chaque fois que
quelqu'un a tort sur Internet. Je perds déjà trop mon temps avec toi.
Non
Si, on tourne en rond, j'ai déjà répondu deux fois à ce paragraphe.
Le fonctionnement normal d'une application qui détecte un truc anormal
n'est pas de faire une bidouille pour aller bosser dans un autre
répertoire.
Il n'y a pas de « fonctionnement normal d'une application qui détecte un
truc anormal » : par définition, si elle détecte un truc anormal, ce n'est
pas son fonctionnement normal, gros malin.
D'autre part, il y a énormément de gens qui, quand ils détectent une
situation anormale, préfèrent la ramener de force à la normale pour pouvoir
continuer à tourner encore un peu plutôt que de signaler immédiatement le
problème. On appelle ça de la programmation défensive.
Je trouve personnellement que c'est _en général_ une mauvaise idée, mais
c'est de fait une mauvaise idée très répandue, et c'est manifestement le
choix qui a été fait pour shm_open dans la glibc.
NiKo , dans le message <4ecd6966$0$27879$426a74cc@news.free.fr>, a
écrit :
Quelle bande de bras cassés tous ces gars qui se servent de /dev/shm !
<https://wiki.archlinux.org/index.php/dev/shm>
« There is currently no text in this page. »
Super, ta référence !
<http://projects.gentoo-fr.org/projects/gentoo-fr/wiki/Tmpfs>
Là, clairement bras cassé. Allez, les plus flagrantes.
* « Je ne saurais trop vous conseillez », « tmpfs est trés simple à utliser
et peux »... no comment.
* Monter /tmp en noexec : merci pour les ./configure qui y font des tests de
compilation et d'exécution.
[... On en trouve à la pelle des choses qui utilisent /dev/shm ...]
On trouve énormément d'idioties sur le web, en effet.
Tu devrais les contacter en urgence !
Je l'ai déjà dit, je ne vais pas prendre mon temps à chaque fois que
quelqu'un a tort sur Internet. Je perds déjà trop mon temps avec toi.
Non
Si, on tourne en rond, j'ai déjà répondu deux fois à ce paragraphe.
Le fonctionnement normal d'une application qui détecte un truc anormal
n'est pas de faire une bidouille pour aller bosser dans un autre
répertoire.
Il n'y a pas de « fonctionnement normal d'une application qui détecte un
truc anormal » : par définition, si elle détecte un truc anormal, ce n'est
pas son fonctionnement normal, gros malin.
D'autre part, il y a énormément de gens qui, quand ils détectent une
situation anormale, préfèrent la ramener de force à la normale pour pouvoir
continuer à tourner encore un peu plutôt que de signaler immédiatement le
problème. On appelle ça de la programmation défensive.
Je trouve personnellement que c'est _en général_ une mauvaise idée, mais
c'est de fait une mauvaise idée très répandue, et c'est manifestement le
choix qui a été fait pour shm_open dans la glibc.
NiKo , dans le message <4ecd6966$0$27879$, a
écrit :Quelle bande de bras cassés tous ces gars qui se servent de /dev/shm !
<https://wiki.archlinux.org/index.php/dev/shm>
« There is currently no text in this page. »
Super, ta référence !
<http://projects.gentoo-fr.org/projects/gentoo-fr/wiki/Tmpfs>
Là, clairement bras cassé. Allez, les plus flagrantes.
* « Je ne saurais trop vous conseillez », « tmpfs est trés simple à utliser
et peux »... no comment.
* Monter /tmp en noexec : merci pour les ./configure qui y font des tests de
compilation et d'exécution.
[... On en trouve à la pelle des choses qui utilisent /dev/shm ...]
On trouve énormément d'idioties sur le web, en effet.
Tu devrais les contacter en urgence !
Je l'ai déjà dit, je ne vais pas prendre mon temps à chaque fois que
quelqu'un a tort sur Internet. Je perds déjà trop mon temps avec toi.
Non
Si, on tourne en rond, j'ai déjà répondu deux fois à ce paragraphe.
Le fonctionnement normal d'une application qui détecte un truc anormal
n'est pas de faire une bidouille pour aller bosser dans un autre
répertoire.
Il n'y a pas de « fonctionnement normal d'une application qui détecte un
truc anormal » : par définition, si elle détecte un truc anormal, ce n'est
pas son fonctionnement normal, gros malin.
D'autre part, il y a énormément de gens qui, quand ils détectent une
situation anormale, préfèrent la ramener de force à la normale pour pouvoir
continuer à tourner encore un peu plutôt que de signaler immédiatement le
problème. On appelle ça de la programmation défensive.
Je trouve personnellement que c'est _en général_ une mauvaise idée, mais
c'est de fait une mauvaise idée très répandue, et c'est manifestement le
choix qui a été fait pour shm_open dans la glibc.
NiKo , dans le message <4ecd7b3b$0$18838$, a
écrit :
<snip>
Écoute, mon gros, au début de cette conversation, tu ne savais pas à quoi
est censé servir /dev/shm, ni que tmpfs pouvait être monté en plusieurs
instances indépendantes. C'est, en fait, moi qui te l'ai appris. La moindre
des choses dans ce genre de situation, c'est de faire preuve d'un peu
d'humilité.
J'ai trop perdu de temps sur ce thread, tu es bouché, ça ne sert à rien de
continuer à te répondre.
En revanche, si d'autres intervenants souhaitent des précisions techniques
que je suis à même d'apporter, ce sera avec plaisir.
NiKo , dans le message <4ecd7b3b$0$18838$426a74cc@news.free.fr>, a
écrit :
<snip>
Écoute, mon gros, au début de cette conversation, tu ne savais pas à quoi
est censé servir /dev/shm, ni que tmpfs pouvait être monté en plusieurs
instances indépendantes. C'est, en fait, moi qui te l'ai appris. La moindre
des choses dans ce genre de situation, c'est de faire preuve d'un peu
d'humilité.
J'ai trop perdu de temps sur ce thread, tu es bouché, ça ne sert à rien de
continuer à te répondre.
En revanche, si d'autres intervenants souhaitent des précisions techniques
que je suis à même d'apporter, ce sera avec plaisir.
NiKo , dans le message <4ecd7b3b$0$18838$, a
écrit :
<snip>
Écoute, mon gros, au début de cette conversation, tu ne savais pas à quoi
est censé servir /dev/shm, ni que tmpfs pouvait être monté en plusieurs
instances indépendantes. C'est, en fait, moi qui te l'ai appris. La moindre
des choses dans ce genre de situation, c'est de faire preuve d'un peu
d'humilité.
J'ai trop perdu de temps sur ce thread, tu es bouché, ça ne sert à rien de
continuer à te répondre.
En revanche, si d'autres intervenants souhaitent des précisions techniques
que je suis à même d'apporter, ce sera avec plaisir.
NiKo , dans le message<4ecd7b3b$0$18838$, a
écrit :
<snip>
Écoute, mon gros, au début de cette conversation, tu ne savais pas à quoi
est censé servir /dev/shm, ni que tmpfs pouvait être monté en plusieurs
instances indépendantes. C'est, en fait, moi qui te l'ai appris. La moindre
des choses dans ce genre de situation, c'est de faire preuve d'un peu
d'humilité.
J'ai trop perdu de temps sur ce thread, tu es bouché, ça ne sert à rien de
continuer à te répondre.
En revanche, si d'autres intervenants souhaitent des précisions techniques
que je suis à même d'apporter, ce sera avec plaisir.
NiKo , dans le message<4ecd7b3b$0$18838$426a74cc@news.free.fr>, a
écrit :
<snip>
Écoute, mon gros, au début de cette conversation, tu ne savais pas à quoi
est censé servir /dev/shm, ni que tmpfs pouvait être monté en plusieurs
instances indépendantes. C'est, en fait, moi qui te l'ai appris. La moindre
des choses dans ce genre de situation, c'est de faire preuve d'un peu
d'humilité.
J'ai trop perdu de temps sur ce thread, tu es bouché, ça ne sert à rien de
continuer à te répondre.
En revanche, si d'autres intervenants souhaitent des précisions techniques
que je suis à même d'apporter, ce sera avec plaisir.
NiKo , dans le message<4ecd7b3b$0$18838$, a
écrit :
<snip>
Écoute, mon gros, au début de cette conversation, tu ne savais pas à quoi
est censé servir /dev/shm, ni que tmpfs pouvait être monté en plusieurs
instances indépendantes. C'est, en fait, moi qui te l'ai appris. La moindre
des choses dans ce genre de situation, c'est de faire preuve d'un peu
d'humilité.
J'ai trop perdu de temps sur ce thread, tu es bouché, ça ne sert à rien de
continuer à te répondre.
En revanche, si d'autres intervenants souhaitent des précisions techniques
que je suis à même d'apporter, ce sera avec plaisir.
Oui, que "noexec" est en réalité sans intérêt au niveau sécurité. NiKo
la grande gueule saura-t-il dire pourquoi ?
Oui, que "noexec" est en réalité sans intérêt au niveau sécurité. NiKo
la grande gueule saura-t-il dire pourquoi ?
Oui, que "noexec" est en réalité sans intérêt au niveau sécurité. NiKo
la grande gueule saura-t-il dire pourquoi ?
Oui, que "noexec" est en réalité sans intérêt au niveau sécurité.
Oui, que "noexec" est en réalité sans intérêt au niveau sécurité.
Oui, que "noexec" est en réalité sans intérêt au niveau sécurité.