Nous avons deux disques USB "My Passport" d'un To (modèles WDBACX0010BBL
et WDBACX0010BRD). J'ai une question sur le fonctionnement des buffers
disques.
Avec l'un ou l'autre disque, monté en ntfs-g3, je lance plusieurs fois la
commande suivante :
# time tar -C $repertoire_disque -c ./ > /dev/null
La 1ère fois, elle met environ 1'10" à se terminer
Un coup d'oeil sur le site de WDt me dit que le taux de transfert peut
atteindre 480Mo/s en USB-2, ce qui est le cas de mon système.
Déjà là, on dépasse la vitesse théorique de 50% !
Mais la 2ème fois, la commande prend 12", à la 3ème 5,2", puis 4.7", etc.
La comande du se comporte de la même manière ; 1'8" puis 3.7" en
enchaînant les appels avec un disque; mais 53" puis 13" avec l'autre.
Je n'ai que 2Go de RAM, il est impossible que les données des disques
soient bufferisées là. Quelqu'un pourrait me dire si cette évolution des
temps de transfert est normale et à quoi elle est dûe dans ce cas ?
Non. Si tu utilises un script PHP qui tourne sur apache, tu ne pourras écrire (s'il est raisonnablement sécurisé) que dans /tmp ou dans un répertoire du même genre parce que le chemin en question risque fort d'être codé en dur dans le logiciel en question.
Tu as mal lu, je parlais de la faille qui te permet d'exécuter quelque chose, pas de celle qui permet d'écrire quelque chose.
La différence entre toi et moi est très simple. J'ai un tas de machines sur le grand ternet, professionnellement parlant, et en plus de quinze ans, la seule qui est tombée est tombée à la suite d'une attaque du réseau local (au travers d'une faille Windows qui plus est). Le jour où tu pourras en dire autant, j'accepterai que tu critique mes opinions sur la sécurisation des systèmes.
En effet, je ne peux pas en dire autant, pour le moment aucune de mes machines n'a été piratée (à ma connaissance, évidemment).
JKB , dans le message <slrnjcuilg.tbp.jkb@rayleigh.systella.fr>, a
écrit :
Non. Si tu utilises un script PHP qui tourne sur apache, tu ne
pourras écrire (s'il est raisonnablement sécurisé) que dans /tmp ou
dans un répertoire du même genre parce que le chemin en question
risque fort d'être codé en dur dans le logiciel en question.
Tu as mal lu, je parlais de la faille qui te permet d'exécuter quelque
chose, pas de celle qui permet d'écrire quelque chose.
La différence entre toi et moi est très simple. J'ai un tas de
machines sur le grand ternet, professionnellement parlant, et en
plus de quinze ans, la seule qui est tombée est tombée à la suite
d'une attaque du réseau local (au travers d'une faille Windows qui
plus est). Le jour où tu pourras en dire autant, j'accepterai que tu
critique mes opinions sur la sécurisation des systèmes.
En effet, je ne peux pas en dire autant, pour le moment aucune de mes
machines n'a été piratée (à ma connaissance, évidemment).
Non. Si tu utilises un script PHP qui tourne sur apache, tu ne pourras écrire (s'il est raisonnablement sécurisé) que dans /tmp ou dans un répertoire du même genre parce que le chemin en question risque fort d'être codé en dur dans le logiciel en question.
Tu as mal lu, je parlais de la faille qui te permet d'exécuter quelque chose, pas de celle qui permet d'écrire quelque chose.
La différence entre toi et moi est très simple. J'ai un tas de machines sur le grand ternet, professionnellement parlant, et en plus de quinze ans, la seule qui est tombée est tombée à la suite d'une attaque du réseau local (au travers d'une faille Windows qui plus est). Le jour où tu pourras en dire autant, j'accepterai que tu critique mes opinions sur la sécurisation des systèmes.
En effet, je ne peux pas en dire autant, pour le moment aucune de mes machines n'a été piratée (à ma connaissance, évidemment).
Nicolas George
JKB , dans le message , a écrit :
Non. Ce répertoire n'a même pas besoin d'exister ! Sous GNV ou EMX, il n'existe pas et pourtant les scripts configure fonctionnnent
Tiens, il me semblait que tu faisais partie de ceux qui se plaignent que configure marche rarement en dehors de Linux.
JKB , dans le message <slrnjcujsp.ui5.jkb@rayleigh.systella.fr>, a
écrit :
Non. Ce répertoire n'a même pas besoin d'exister ! Sous GNV ou EMX,
il n'existe pas et pourtant les scripts configure fonctionnnent
Tiens, il me semblait que tu faisais partie de ceux qui se plaignent que
configure marche rarement en dehors de Linux.
Herve Autret , dans le message <4ecf6fcd$0$24979$, a écrit :
... sans précautions.
Et les précautions, en l'occurrence, c'est précisément se renseigner. Merci de ton soutien.
Ceci dit, le fait que /dev/shm soit _réservé_ à la libc n'est pas avéré pour moi.
Et le fait que ~/.fontconfig soit réservé à la bibliothèque fontconfig, tu considères que c'est avéré ?
Si je veux monitorer le contenu de mon /dev/shm, je peux faire un ls toutes les X secondes
Et tu rates tous les fichiers dont la durée de vie est inférieure à ça.
Qu'y aurait-il comme moyen plus propre ?
Surveiller le contenu d'un répertoire ne fait jamais partie d'une solution propre.
Parmi les trucs qu'on peut faire, il y en a qu'on peut faire sans risque.
Oui.
Certes, mais tant je ne sais pas distinguer les trucs nocifs des autres, je ne suis pas plus avancé.
Et donc tu te renseignes.
Concernant /dev/shm, soit tu ne sais pas et tu n'y touches pas, soit tu sais et donc tu sais aussi qu'il y a de meilleures solutions (/tmp).
JKB
Le 25 Nov 2011 10:39:18 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Non. Ce répertoire n'a même pas besoin d'exister ! Sous GNV ou EMX, il n'existe pas et pourtant les scripts configure fonctionnnent
Tiens, il me semblait que tu faisais partie de ceux qui se plaignent que configure marche rarement en dehors de Linux.
En dehors du monde _Unix_, ce qui est différent. Le problème de configure sous EMX ou sous GNV vient du fait que configure utilise un tas de bashismes douteux et suppose que la longueur de la ligne de commande est plus longue que ce qu'il arrive à générer comme commande. Sous EMX, la longueur de la ligne de commande est de 8K. Configure n'aime pas et ça n'a strictement rien à voir avec la présence ou non d'un /tmp. Sous GNV, ça merdoie pour d'autres raisons, mais raisons qui n'ont elles non plus rien à voir avec le schmilblick.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le 25 Nov 2011 10:39:18 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnjcujsp.ui5.jkb@rayleigh.systella.fr>, a
écrit :
Non. Ce répertoire n'a même pas besoin d'exister ! Sous GNV ou EMX,
il n'existe pas et pourtant les scripts configure fonctionnnent
Tiens, il me semblait que tu faisais partie de ceux qui se plaignent que
configure marche rarement en dehors de Linux.
En dehors du monde _Unix_, ce qui est différent. Le problème de
configure sous EMX ou sous GNV vient du fait que configure utilise
un tas de bashismes douteux et suppose que la longueur de la ligne
de commande est plus longue que ce qu'il arrive à générer comme
commande. Sous EMX, la longueur de la ligne de commande est de 8K.
Configure n'aime pas et ça n'a strictement rien à voir avec la
présence ou non d'un /tmp. Sous GNV, ça merdoie pour d'autres
raisons, mais raisons qui n'ont elles non plus rien à voir avec le
schmilblick.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 25 Nov 2011 10:39:18 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Non. Ce répertoire n'a même pas besoin d'exister ! Sous GNV ou EMX, il n'existe pas et pourtant les scripts configure fonctionnnent
Tiens, il me semblait que tu faisais partie de ceux qui se plaignent que configure marche rarement en dehors de Linux.
En dehors du monde _Unix_, ce qui est différent. Le problème de configure sous EMX ou sous GNV vient du fait que configure utilise un tas de bashismes douteux et suppose que la longueur de la ligne de commande est plus longue que ce qu'il arrive à générer comme commande. Sous EMX, la longueur de la ligne de commande est de 8K. Configure n'aime pas et ça n'a strictement rien à voir avec la présence ou non d'un /tmp. Sous GNV, ça merdoie pour d'autres raisons, mais raisons qui n'ont elles non plus rien à voir avec le schmilblick.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
JKB
Le 25 Nov 2011 10:38:11 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Non. Si tu utilises un script PHP qui tourne sur apache, tu ne pourras écrire (s'il est raisonnablement sécurisé) que dans /tmp ou dans un répertoire du même genre parce que le chemin en question risque fort d'être codé en dur dans le logiciel en question.
Tu as mal lu, je parlais de la faille qui te permet d'exécuter quelque chose, pas de celle qui permet d'écrire quelque chose.
C'est toi qui n'a rien compris. Avant d'exécuter quelque chose, il faut que ce quelque chose puisse soit être exécuté directement (cas rare), soit être écrit quelque part sur le disque puis être exécuté en utilisant une faille (cas nettement moins rare). Ta faille ne te demande pas gentiment avec quel interprète tu veux lancer ton attaque. Je te laisse conclure.
La différence entre toi et moi est très simple. J'ai un tas de machines sur le grand ternet, professionnellement parlant, et en plus de quinze ans, la seule qui est tombée est tombée à la suite d'une attaque du réseau local (au travers d'une faille Windows qui plus est). Le jour où tu pourras en dire autant, j'accepterai que tu critique mes opinions sur la sécurisation des systèmes.
En effet, je ne peux pas en dire autant, pour le moment aucune de mes machines n'a été piratée (à ma connaissance, évidemment).
Moi, vois-tu, je _sais_ que mes machines sont saines. D'une part les logs sont déportés (sur du SQL avec une autorisation juste sur le INSERT, même pas sur le SELECT), mais j'ai aussi un script maison qui hashe les exécutables toutes les semaines et qui gueule s'il y a un truc nouveau et pas déclaré. Naturellement, ce truc se hashe lui-même et compare sa signature sur la base distante qui n'est accessible qu'en SELECT. Tu vas me dire qu'un utilisateur peut aller écrire une saleté quelque part dans un répertoire caché. Oui, mais dans les logs du scanner, je vais avoir une alerte sur ce fichier. La seule difficulté de la technique est la mise à jour de l'OS qui est un peu compliquée mais ça se fait. Tu vas me dire aussi que le gentil pirate peut lancer un truc en mémoire et le virer du disque. C'est parfaitement exact, mais ce genre de truc se détecte. Lorsque tu as un sshd qui écoute sur le port 22 et 80 en même temps (ce fut un grand classique), ça se voit en utilisant les bons outils.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le 25 Nov 2011 10:38:11 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnjcuilg.tbp.jkb@rayleigh.systella.fr>, a
écrit :
Non. Si tu utilises un script PHP qui tourne sur apache, tu ne
pourras écrire (s'il est raisonnablement sécurisé) que dans /tmp ou
dans un répertoire du même genre parce que le chemin en question
risque fort d'être codé en dur dans le logiciel en question.
Tu as mal lu, je parlais de la faille qui te permet d'exécuter quelque
chose, pas de celle qui permet d'écrire quelque chose.
C'est toi qui n'a rien compris. Avant d'exécuter quelque chose, il
faut que ce quelque chose puisse soit être exécuté directement (cas
rare), soit être écrit quelque part sur le disque puis être exécuté
en utilisant une faille (cas nettement moins rare). Ta faille ne te
demande pas gentiment avec quel interprète tu veux lancer ton
attaque. Je te laisse conclure.
La différence entre toi et moi est très simple. J'ai un tas de
machines sur le grand ternet, professionnellement parlant, et en
plus de quinze ans, la seule qui est tombée est tombée à la suite
d'une attaque du réseau local (au travers d'une faille Windows qui
plus est). Le jour où tu pourras en dire autant, j'accepterai que tu
critique mes opinions sur la sécurisation des systèmes.
En effet, je ne peux pas en dire autant, pour le moment aucune de mes
machines n'a été piratée (à ma connaissance, évidemment).
Moi, vois-tu, je _sais_ que mes machines sont saines. D'une part les
logs sont déportés (sur du SQL avec une autorisation juste sur le
INSERT, même pas sur le SELECT), mais j'ai aussi un script maison
qui hashe les exécutables toutes les semaines et qui gueule s'il y a
un truc nouveau et pas déclaré. Naturellement, ce truc se hashe
lui-même et compare sa signature sur la base distante qui n'est
accessible qu'en SELECT. Tu vas me dire qu'un utilisateur peut aller
écrire une saleté quelque part dans un répertoire caché. Oui,
mais dans les logs du scanner, je vais avoir une alerte sur ce
fichier. La seule difficulté de la technique est la mise à jour de
l'OS qui est un peu compliquée mais ça se fait. Tu vas me dire aussi
que le gentil pirate peut lancer un truc en mémoire et le virer du
disque. C'est parfaitement exact, mais ce genre de truc se détecte.
Lorsque tu as un sshd qui écoute sur le port 22 et 80 en même temps
(ce fut un grand classique), ça se voit en utilisant les bons outils.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 25 Nov 2011 10:38:11 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Non. Si tu utilises un script PHP qui tourne sur apache, tu ne pourras écrire (s'il est raisonnablement sécurisé) que dans /tmp ou dans un répertoire du même genre parce que le chemin en question risque fort d'être codé en dur dans le logiciel en question.
Tu as mal lu, je parlais de la faille qui te permet d'exécuter quelque chose, pas de celle qui permet d'écrire quelque chose.
C'est toi qui n'a rien compris. Avant d'exécuter quelque chose, il faut que ce quelque chose puisse soit être exécuté directement (cas rare), soit être écrit quelque part sur le disque puis être exécuté en utilisant une faille (cas nettement moins rare). Ta faille ne te demande pas gentiment avec quel interprète tu veux lancer ton attaque. Je te laisse conclure.
La différence entre toi et moi est très simple. J'ai un tas de machines sur le grand ternet, professionnellement parlant, et en plus de quinze ans, la seule qui est tombée est tombée à la suite d'une attaque du réseau local (au travers d'une faille Windows qui plus est). Le jour où tu pourras en dire autant, j'accepterai que tu critique mes opinions sur la sécurisation des systèmes.
En effet, je ne peux pas en dire autant, pour le moment aucune de mes machines n'a été piratée (à ma connaissance, évidemment).
Moi, vois-tu, je _sais_ que mes machines sont saines. D'une part les logs sont déportés (sur du SQL avec une autorisation juste sur le INSERT, même pas sur le SELECT), mais j'ai aussi un script maison qui hashe les exécutables toutes les semaines et qui gueule s'il y a un truc nouveau et pas déclaré. Naturellement, ce truc se hashe lui-même et compare sa signature sur la base distante qui n'est accessible qu'en SELECT. Tu vas me dire qu'un utilisateur peut aller écrire une saleté quelque part dans un répertoire caché. Oui, mais dans les logs du scanner, je vais avoir une alerte sur ce fichier. La seule difficulté de la technique est la mise à jour de l'OS qui est un peu compliquée mais ça se fait. Tu vas me dire aussi que le gentil pirate peut lancer un truc en mémoire et le virer du disque. C'est parfaitement exact, mais ce genre de truc se détecte. Lorsque tu as un sshd qui écoute sur le port 22 et 80 en même temps (ce fut un grand classique), ça se voit en utilisant les bons outils.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Nicolas George
JKB , dans le message , a écrit :
Moi, vois-tu, je _sais_ que mes machines sont saines.
Ah ouais, quand même !
JKB , dans le message <slrnjcv20v.g08.jkb@rayleigh.systella.fr>, a
écrit :
Moi, vois-tu, je _sais_ que mes machines sont saines.
Moi, vois-tu, je _sais_ que mes machines sont saines.
Ah ouais, quand même !
JKB
Le 25 Nov 2011 12:22:27 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Moi, vois-tu, je _sais_ que mes machines sont saines.
Ah ouais, quand même !
Exactement. Comme d'habitude, tu ne retiens que ce qui t'arrange. Remarque j'ai mis 'je _sais_' à la place de 'je suis quasiment sûr', uniquement pour toi, parce que tu allais relever ça sans lire le reste. Je ne me suis pas trompé.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le 25 Nov 2011 12:22:27 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnjcv20v.g08.jkb@rayleigh.systella.fr>, a
écrit :
Moi, vois-tu, je _sais_ que mes machines sont saines.
Ah ouais, quand même !
Exactement. Comme d'habitude, tu ne retiens que ce qui t'arrange.
Remarque j'ai mis 'je _sais_' à la place de 'je suis quasiment sûr',
uniquement pour toi, parce que tu allais relever ça sans lire le reste.
Je ne me suis pas trompé.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 25 Nov 2011 12:22:27 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Moi, vois-tu, je _sais_ que mes machines sont saines.
Ah ouais, quand même !
Exactement. Comme d'habitude, tu ne retiens que ce qui t'arrange. Remarque j'ai mis 'je _sais_' à la place de 'je suis quasiment sûr', uniquement pour toi, parce que tu allais relever ça sans lire le reste. Je ne me suis pas trompé.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Herve Autret
Nicolas George :
[] Ceci dit, le fait que /dev/shm soit _réservé_ à la libc n'est pas avéré pour moi.
Et le fait que ~/.fontconfig soit réservé à la bibliothèque fontconfig, tu considères que c'est avéré ?
Si on me le demande, je dirai que c'est le cas. Mais en conclure que de ce fait, /dev/shm serait réservé à la libc serait une inférence abusive. Inférence dûe au rapprochement que tu as fait entre la libc et fontconfig, que je trouve parfaitement arbitraire par ailleurs. Dans un but didactique, certes, mais avec un propos à la fois argumenté (tu sais pas mal de choses) et auto-référencé, ce qui est moins recevable.
Par exemple : .bash_profile est relatif à bash, ce que confirme le man. Si j'en déduis l'hypothèse selon laquelle .fontconfig est relatif à fontconfig, je ne prends pas un trop gros risque. Mais après ? Après, je n'écrirai pas dedans car --laissons de côté les inconvénients-- je n'y ai aucun avantage en tant qu'utilisateur.
Par contre, si ce même utilisateur veut utiliser /dev/shm car c'est plus rapide que le /tmp natif des distros standards, il y voit un avantage et il peut le faire : il le fait et il ne croit pas que ce soit une bêtise. Maintenant, j'ai pris connaissance des docs que tu as citées, et ma prochaine install aura sans doute le /tmp monté en tmpfs avec un plus gros swap.
Si je veux monitorer le contenu de mon /dev/shm, je peux faire un ls toutes les X secondes
Et tu rates tous les fichiers dont la durée de vie est inférieure à ça.
Durée inférieure mais non nulle. Je n'aurai pas le contenu réel du répertoire mais s'il y a des mouvements je finirai bien par les voir, non ?
à + -- Hervé
Nicolas George :
[] Ceci dit, le fait que /dev/shm soit _réservé_ à la libc
n'est pas avéré pour moi.
Et le fait que ~/.fontconfig soit réservé à la bibliothèque fontconfig,
tu considères que c'est avéré ?
Si on me le demande, je dirai que c'est le cas. Mais en conclure que de
ce fait, /dev/shm serait réservé à la libc serait une inférence abusive.
Inférence dûe au rapprochement que tu as fait entre la libc et
fontconfig, que je trouve parfaitement arbitraire par ailleurs. Dans un
but didactique, certes, mais avec un propos à la fois argumenté (tu sais
pas mal de choses) et auto-référencé, ce qui est moins recevable.
Par exemple : .bash_profile est relatif à bash, ce que confirme le man.
Si j'en déduis l'hypothèse selon laquelle .fontconfig est relatif à
fontconfig, je ne prends pas un trop gros risque. Mais après ? Après, je
n'écrirai pas dedans car --laissons de côté les inconvénients-- je n'y ai
aucun avantage en tant qu'utilisateur.
Par contre, si ce même utilisateur veut utiliser /dev/shm car c'est plus
rapide que le /tmp natif des distros standards, il y voit un avantage et
il peut le faire : il le fait et il ne croit pas que ce soit une bêtise.
Maintenant, j'ai pris connaissance des docs que tu as citées, et ma
prochaine install aura sans doute le /tmp monté en tmpfs avec un plus gros
swap.
Si je veux monitorer le contenu de mon /dev/shm, je peux faire un ls
toutes les X secondes
Et tu rates tous les fichiers dont la durée de vie est inférieure à ça.
Durée inférieure mais non nulle. Je n'aurai pas le contenu réel du
répertoire mais s'il y a des mouvements je finirai bien par les voir,
non ?
[] Ceci dit, le fait que /dev/shm soit _réservé_ à la libc n'est pas avéré pour moi.
Et le fait que ~/.fontconfig soit réservé à la bibliothèque fontconfig, tu considères que c'est avéré ?
Si on me le demande, je dirai que c'est le cas. Mais en conclure que de ce fait, /dev/shm serait réservé à la libc serait une inférence abusive. Inférence dûe au rapprochement que tu as fait entre la libc et fontconfig, que je trouve parfaitement arbitraire par ailleurs. Dans un but didactique, certes, mais avec un propos à la fois argumenté (tu sais pas mal de choses) et auto-référencé, ce qui est moins recevable.
Par exemple : .bash_profile est relatif à bash, ce que confirme le man. Si j'en déduis l'hypothèse selon laquelle .fontconfig est relatif à fontconfig, je ne prends pas un trop gros risque. Mais après ? Après, je n'écrirai pas dedans car --laissons de côté les inconvénients-- je n'y ai aucun avantage en tant qu'utilisateur.
Par contre, si ce même utilisateur veut utiliser /dev/shm car c'est plus rapide que le /tmp natif des distros standards, il y voit un avantage et il peut le faire : il le fait et il ne croit pas que ce soit une bêtise. Maintenant, j'ai pris connaissance des docs que tu as citées, et ma prochaine install aura sans doute le /tmp monté en tmpfs avec un plus gros swap.
Si je veux monitorer le contenu de mon /dev/shm, je peux faire un ls toutes les X secondes
Et tu rates tous les fichiers dont la durée de vie est inférieure à ça.
Durée inférieure mais non nulle. Je n'aurai pas le contenu réel du répertoire mais s'il y a des mouvements je finirai bien par les voir, non ?
à + -- Hervé
Hugues
Ce cher Herve Autret a posté :
ma prochaine install aura sans doute le /tmp monté en tmpfs avec un plus gros swap.
Hum, quel est le rapport avec la swap ?
Si je veux monitorer le contenu de mon /dev/shm, je peux faire un ls toutes les X secondes
Et tu rates tous les fichiers dont la durée de vie est inférieure à ça.
Durée inférieure mais non nulle. Je n'aurai pas le contenu réel du répertoire mais s'il y a des mouvements je finirai bien par les voir, non ?
Si ça peut te faire plaisir. Mais je rejoins Nicolas : ça ne sert strictement à rien.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Ce cher Herve Autret <autret@lussinan.org> a posté :
ma prochaine install aura sans doute le /tmp monté en tmpfs avec un
plus gros swap.
Hum, quel est le rapport avec la swap ?
Si je veux monitorer le contenu de mon /dev/shm, je peux faire un ls
toutes les X secondes
Et tu rates tous les fichiers dont la durée de vie est inférieure à ça.
Durée inférieure mais non nulle. Je n'aurai pas le contenu réel du
répertoire mais s'il y a des mouvements je finirai bien par les voir,
non ?
Si ça peut te faire plaisir.
Mais je rejoins Nicolas : ça ne sert strictement à rien.
ma prochaine install aura sans doute le /tmp monté en tmpfs avec un plus gros swap.
Hum, quel est le rapport avec la swap ?
Si je veux monitorer le contenu de mon /dev/shm, je peux faire un ls toutes les X secondes
Et tu rates tous les fichiers dont la durée de vie est inférieure à ça.
Durée inférieure mais non nulle. Je n'aurai pas le contenu réel du répertoire mais s'il y a des mouvements je finirai bien par les voir, non ?
Si ça peut te faire plaisir. Mais je rejoins Nicolas : ça ne sert strictement à rien.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Nicolas George
JKB , dans le message , a écrit :
Remarque j'ai mis 'je _sais_' à la place de 'je suis quasiment sûr',
Eh bien tu as eu tort. J'ai envie de dire que seul un guignol est sûr de ne pas avoir été piraté. D'ailleurs, il me semble t'avoir déjà vu tenir les mêmes propos.
uniquement pour toi, parce que tu allais relever ça sans lire le reste.
J'ai lu le reste, je t'ai déjà dit que je ne souhaitais pas répondre à ces arguments rebattus.
JKB , dans le message <slrnjcv271.g08.jkb@rayleigh.systella.fr>, a
écrit :
Remarque j'ai mis 'je _sais_' à la place de 'je suis quasiment sûr',
Eh bien tu as eu tort. J'ai envie de dire que seul un guignol est sûr de ne
pas avoir été piraté. D'ailleurs, il me semble t'avoir déjà vu tenir les
mêmes propos.
uniquement pour toi, parce que tu allais relever ça sans lire le reste.
J'ai lu le reste, je t'ai déjà dit que je ne souhaitais pas répondre à ces
arguments rebattus.
Remarque j'ai mis 'je _sais_' à la place de 'je suis quasiment sûr',
Eh bien tu as eu tort. J'ai envie de dire que seul un guignol est sûr de ne pas avoir été piraté. D'ailleurs, il me semble t'avoir déjà vu tenir les mêmes propos.
uniquement pour toi, parce que tu allais relever ça sans lire le reste.
J'ai lu le reste, je t'ai déjà dit que je ne souhaitais pas répondre à ces arguments rebattus.
