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 ?
Sauf que tu n'as pas _forcément_ accès à un shell ou à autre chose pour changer lesdites options.
Si tu peux exécuter un programme, tu peux en exécuter un autre. Si tu peux exécuter un programme dans /tmp, tu peux exécuter un shell pour faire des choses plus compliquées.
Maintenant, je connais depuis longtemps tes opinions en matière de sécurité, tu sais les défendre mais je n'adhère pas à tes arguments. Je ne vois pas l'intérêt de reprendre une discussion qu'on a déjà eue cent fois en vain.
JKB , dans le message <slrnjct31c.oed.jkb@rayleigh.systella.fr>, a
écrit :
Sauf que tu n'as pas _forcément_ accès à un shell ou à autre chose
pour changer lesdites options.
Si tu peux exécuter un programme, tu peux en exécuter un autre. Si tu peux
exécuter un programme dans /tmp, tu peux exécuter un shell pour faire des
choses plus compliquées.
Maintenant, je connais depuis longtemps tes opinions en matière de sécurité,
tu sais les défendre mais je n'adhère pas à tes arguments. Je ne vois pas
l'intérêt de reprendre une discussion qu'on a déjà eue cent fois en vain.
Sauf que tu n'as pas _forcément_ accès à un shell ou à autre chose pour changer lesdites options.
Si tu peux exécuter un programme, tu peux en exécuter un autre. Si tu peux exécuter un programme dans /tmp, tu peux exécuter un shell pour faire des choses plus compliquées.
Maintenant, je connais depuis longtemps tes opinions en matière de sécurité, tu sais les défendre mais je n'adhère pas à tes arguments. Je ne vois pas l'intérêt de reprendre une discussion qu'on a déjà eue cent fois en vain.
Mauvaise réponse. mktemp crée un fichier temporaire. Rien ne te garantit qu'il est créé dans /tmp.
L'argument à mktemp semble contredire cette affirmation.
Je peux te citer au moins deux systèmes Unix où ce n'est pas vrai.
Mais peu importe : quand bien même ce serait vrai, ça veut dire que le répertoire destiné aux fichiers temporaires doit être accessible en exécution pour que configure fonctionne. Que certains Unix aient eu la lubie de l'appeler autrement que /tmp n'est qu'un bizarrerie historique de plus sans importance.
JKB , dans le message <slrnjct398.oed.jkb@rayleigh.systella.fr>, a
écrit :
Mauvaise réponse. mktemp crée un fichier temporaire. Rien ne te
garantit qu'il est créé dans /tmp.
L'argument à mktemp semble contredire cette affirmation.
Je peux te citer au moins deux
systèmes Unix où ce n'est pas vrai.
Mais peu importe : quand bien même ce serait vrai, ça veut dire que le
répertoire destiné aux fichiers temporaires doit être accessible en
exécution pour que configure fonctionne. Que certains Unix aient eu la lubie
de l'appeler autrement que /tmp n'est qu'un bizarrerie historique de plus
sans importance.
Mauvaise réponse. mktemp crée un fichier temporaire. Rien ne te garantit qu'il est créé dans /tmp.
L'argument à mktemp semble contredire cette affirmation.
Je peux te citer au moins deux systèmes Unix où ce n'est pas vrai.
Mais peu importe : quand bien même ce serait vrai, ça veut dire que le répertoire destiné aux fichiers temporaires doit être accessible en exécution pour que configure fonctionne. Que certains Unix aient eu la lubie de l'appeler autrement que /tmp n'est qu'un bizarrerie historique de plus sans importance.
Nicolas George
Herve Autret , dans le message <4ece896c$0$10036$, a écrit :
Dit comme ça, ça me paraît relever d'un principe de précaution à la limite de l'excès. Où puis-je me renseigner pour savoir ce que la libc est censée écrire dans ce répertoire ?
Dans le code source de la libc si vraiment ça t'intéresse.
Je n'arrive pas à trouver où une telle chose serait écrite.
Dans ce principe : si on ne sait pas à quoi ça sert, on ne touche pas. Éventuellement on se renseigne, mais par défaut on ne touche pas.
Tu ne trouveras pas non plus de documentation te disant de ne pas éditer un fichier sqlite avec nano, de ne pas mettre des données idiotes dans ~/.fontconfig ou que sais-je. C'est le bon sens le plus élémentaire qui te le dit.
Herve Autret , dans le message <4ece896c$0$10036$426a74cc@news.free.fr>,
a écrit :
Dit comme ça, ça me paraît relever d'un principe de précaution à la
limite de l'excès. Où puis-je me renseigner pour savoir ce que la libc
est censée écrire dans ce répertoire ?
Dans le code source de la libc si vraiment ça t'intéresse.
Je n'arrive pas à trouver où une telle chose serait écrite.
Dans ce principe : si on ne sait pas à quoi ça sert, on ne touche pas.
Éventuellement on se renseigne, mais par défaut on ne touche pas.
Tu ne trouveras pas non plus de documentation te disant de ne pas éditer un
fichier sqlite avec nano, de ne pas mettre des données idiotes dans
~/.fontconfig ou que sais-je. C'est le bon sens le plus élémentaire qui te
le dit.
Herve Autret , dans le message <4ece896c$0$10036$, a écrit :
Dit comme ça, ça me paraît relever d'un principe de précaution à la limite de l'excès. Où puis-je me renseigner pour savoir ce que la libc est censée écrire dans ce répertoire ?
Dans le code source de la libc si vraiment ça t'intéresse.
Je n'arrive pas à trouver où une telle chose serait écrite.
Dans ce principe : si on ne sait pas à quoi ça sert, on ne touche pas. Éventuellement on se renseigne, mais par défaut on ne touche pas.
Tu ne trouveras pas non plus de documentation te disant de ne pas éditer un fichier sqlite avec nano, de ne pas mettre des données idiotes dans ~/.fontconfig ou que sais-je. C'est le bon sens le plus élémentaire qui te le dit.
Trinine
Le Thu, 24 Nov 2011 18:45:25 +0000, Nicolas George a écrit :
Mais peu importe : quand bien même ce serait vrai, ça veut dire que le répertoire destiné aux fichiers temporaires doit être accessible en exécution pour que configure fonctionne. Que certains Unix aient eu la
lubie
de l'appeler autrement que /tmp n'est qu'un bizarrerie historique de
plus
sans importance.
Petite précision : pour revenir à Gentoo, la commande emerge n'utilise pas /tmp mais le répertoire défini dans /etc/make.conf. Par défaut, ce n'est d'ailleurs pas /tmp mais /var/tmp (et apparemment certains s'amusent à utiliser /dev/shm). Du coup, configuration comme compilation sont parfaitement possibles avec un /tmp monté en noexec : configure et cie sont appelés via des wrappers comme "econf" par exemple, voir http://devmanual.gentoo.org/function-reference/build-functions/index.html
La remarque reste par contre valable pour les compilations faites à la main (mais c'est plutôt rare sous Gentoo).
T.
Le Thu, 24 Nov 2011 18:45:25 +0000, Nicolas George a écrit :
Mais peu importe : quand bien même ce serait vrai, ça veut dire que le
répertoire destiné aux fichiers temporaires doit être accessible en
exécution pour que configure fonctionne. Que certains Unix aient eu la
lubie
de l'appeler autrement que /tmp n'est qu'un bizarrerie historique de
plus
sans importance.
Petite précision : pour revenir à Gentoo, la commande emerge n'utilise
pas /tmp mais le répertoire défini dans /etc/make.conf. Par défaut, ce
n'est d'ailleurs pas /tmp mais /var/tmp (et apparemment certains
s'amusent à utiliser /dev/shm). Du coup, configuration comme compilation
sont parfaitement possibles avec un /tmp monté en noexec : configure et
cie sont appelés via des wrappers comme "econf" par exemple, voir
http://devmanual.gentoo.org/function-reference/build-functions/index.html
La remarque reste par contre valable pour les compilations faites à la
main (mais c'est plutôt rare sous Gentoo).
Le Thu, 24 Nov 2011 18:45:25 +0000, Nicolas George a écrit :
Mais peu importe : quand bien même ce serait vrai, ça veut dire que le répertoire destiné aux fichiers temporaires doit être accessible en exécution pour que configure fonctionne. Que certains Unix aient eu la
lubie
de l'appeler autrement que /tmp n'est qu'un bizarrerie historique de
plus
sans importance.
Petite précision : pour revenir à Gentoo, la commande emerge n'utilise pas /tmp mais le répertoire défini dans /etc/make.conf. Par défaut, ce n'est d'ailleurs pas /tmp mais /var/tmp (et apparemment certains s'amusent à utiliser /dev/shm). Du coup, configuration comme compilation sont parfaitement possibles avec un /tmp monté en noexec : configure et cie sont appelés via des wrappers comme "econf" par exemple, voir http://devmanual.gentoo.org/function-reference/build-functions/index.html
La remarque reste par contre valable pour les compilations faites à la main (mais c'est plutôt rare sous Gentoo).
T.
JKB
Le 24 Nov 2011 18:42:38 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Sauf que tu n'as pas _forcément_ accès à un shell ou à autre chose pour changer lesdites options.
Si tu peux exécuter un programme, tu peux en exécuter un autre. Si tu peux exécuter un programme dans /tmp, tu peux exécuter un shell pour faire des choses plus compliquées.
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. Là, le fait de ne pas pouvoir exécuter ton soft pour utiliser une faille changera tout. Mais après tout, tu as parfaitement le droit d'autoriser sur un serveur de prod l'exécution des scripts dans les répertoires temporaires d'apache ou de PHP. Comme tu as parfaitement le droit de coller un compilateur C sur la même machine. Autant coller un noexec sur une machine de développement est idiot, autant ne pas le mettre sur une machine potentiellement attaquable est ridicule.
Maintenant, je connais depuis longtemps tes opinions en matière de sécurité, tu sais les défendre mais je n'adhère pas à tes arguments. Je ne vois pas l'intérêt de reprendre une discussion qu'on a déjà eue cent fois en vain.
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.
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 24 Nov 2011 18:42:38 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnjct31c.oed.jkb@rayleigh.systella.fr>, a
écrit :
Sauf que tu n'as pas _forcément_ accès à un shell ou à autre chose
pour changer lesdites options.
Si tu peux exécuter un programme, tu peux en exécuter un autre. Si tu peux
exécuter un programme dans /tmp, tu peux exécuter un shell pour faire des
choses plus compliquées.
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. Là, le
fait de ne pas pouvoir exécuter ton soft pour utiliser une faille
changera tout. Mais après tout, tu as parfaitement le droit
d'autoriser sur un serveur de prod l'exécution des scripts dans les
répertoires temporaires d'apache ou de PHP. Comme tu as parfaitement
le droit de coller un compilateur C sur la même machine. Autant
coller un noexec sur une machine de développement est idiot, autant
ne pas le mettre sur une machine potentiellement attaquable est
ridicule.
Maintenant, je connais depuis longtemps tes opinions en matière de sécurité,
tu sais les défendre mais je n'adhère pas à tes arguments. Je ne vois pas
l'intérêt de reprendre une discussion qu'on a déjà eue cent fois en vain.
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.
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 24 Nov 2011 18:42:38 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Sauf que tu n'as pas _forcément_ accès à un shell ou à autre chose pour changer lesdites options.
Si tu peux exécuter un programme, tu peux en exécuter un autre. Si tu peux exécuter un programme dans /tmp, tu peux exécuter un shell pour faire des choses plus compliquées.
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. Là, le fait de ne pas pouvoir exécuter ton soft pour utiliser une faille changera tout. Mais après tout, tu as parfaitement le droit d'autoriser sur un serveur de prod l'exécution des scripts dans les répertoires temporaires d'apache ou de PHP. Comme tu as parfaitement le droit de coller un compilateur C sur la même machine. Autant coller un noexec sur une machine de développement est idiot, autant ne pas le mettre sur une machine potentiellement attaquable est ridicule.
Maintenant, je connais depuis longtemps tes opinions en matière de sécurité, tu sais les défendre mais je n'adhère pas à tes arguments. Je ne vois pas l'intérêt de reprendre une discussion qu'on a déjà eue cent fois en vain.
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.
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 24 Nov 2011 18:45:25 GMT, Nicolas George <nicolas$ écrivait :
Mauvaise réponse. mktemp crée un fichier temporaire. Rien ne te garantit qu'il est créé dans /tmp.
L'argument à mktemp semble contredire cette affirmation.
Encore une fois, tu ferais bien de sortir du monde Linux ou à la rigueur BSD. J'ai devant moi un système qui 'aliase' le /tmp. Je te laisse chercher lequel. Tu devrais arrêter de sortir péremptoirement des énormités surtout en lisant la page man de Linux ou d'un quelconque BSD. Tout ce que ta ligne signifie, c'est que mktemp va te créer un répertoire qui sera vu comme étant dans /tmp pour le shell. Mais si ça se trouve, ton /tmp n'existe même pas. En l'occurrence, j'ai devant moi un système où cette commande fonctionne alors qu'il n'y a aucun /tmp sur le disque !
J'aimerais aussi que tu regardes très finement ce que fait cette commande et à quoi ressemblent les lignes suivantes. Tu comprendras peut-être en quoi ton assertion est une énormité et pourquoi le flag exec n'est pas nécessaire. Je t'aide, autoconf fait une subtile différence entre les exécutables créés par gcc et les macros d'autoconf et les scripts (awk ou autres) qui sont appelés avec leur interprète sur la ligne de commande.
Je peux te citer au moins deux systèmes Unix où ce n'est pas vrai.
Mais peu importe : quand bien même ce serait vrai, ça veut dire que le répertoire destiné aux fichiers temporaires doit être accessible en exécution pour que configure fonctionne.
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 parfaitement.
Que certains Unix aient eu la lubie de l'appeler autrement que /tmp n'est qu'un bizarrerie historique de plus sans importance.
Définition : est bizarre tout ce que Nicols George ne comprend pas. Il y a une justification au choix qui a été fait sous Solaris. Comme il y a une justification au choix qui a été fait sous d'autres Unix ou d'autres OS. Et ces raisons ne sont pas des bizarreries. Il est d'ailleurs moins idiot d'avoir un répertoire temporaire dans /var que dans /tmp où la plupart du temps il se trouve sur le rootdevice.
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 24 Nov 2011 18:45:25 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnjct398.oed.jkb@rayleigh.systella.fr>, a
écrit :
Mauvaise réponse. mktemp crée un fichier temporaire. Rien ne te
garantit qu'il est créé dans /tmp.
L'argument à mktemp semble contredire cette affirmation.
Encore une fois, tu ferais bien de sortir du monde Linux ou à la
rigueur BSD. J'ai devant moi un système qui 'aliase' le /tmp. Je te
laisse chercher lequel. Tu devrais arrêter de sortir péremptoirement
des énormités surtout en lisant la page man de Linux ou d'un
quelconque BSD. Tout ce que ta ligne signifie, c'est que mktemp va
te créer un répertoire qui sera vu comme étant dans /tmp pour
le shell. Mais si ça se trouve, ton /tmp n'existe même pas. En
l'occurrence, j'ai devant moi un système où cette commande
fonctionne alors qu'il n'y a aucun /tmp sur le disque !
J'aimerais aussi que tu regardes très finement ce que fait cette
commande et à quoi ressemblent les lignes suivantes. Tu comprendras
peut-être en quoi ton assertion est une énormité et pourquoi le flag
exec n'est pas nécessaire. Je t'aide, autoconf fait une subtile
différence entre les exécutables créés par gcc et les macros
d'autoconf et les scripts (awk ou autres) qui sont appelés avec leur
interprète sur la ligne de commande.
Je peux te citer au moins deux
systèmes Unix où ce n'est pas vrai.
Mais peu importe : quand bien même ce serait vrai, ça veut dire que le
répertoire destiné aux fichiers temporaires doit être accessible en
exécution pour que configure fonctionne.
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
parfaitement.
Que certains Unix aient eu la lubie
de l'appeler autrement que /tmp n'est qu'un bizarrerie historique de plus
sans importance.
Définition : est bizarre tout ce que Nicols George ne comprend pas.
Il y a une justification au choix qui a été fait sous Solaris. Comme
il y a une justification au choix qui a été fait sous d'autres Unix
ou d'autres OS. Et ces raisons ne sont pas des bizarreries. Il est
d'ailleurs moins idiot d'avoir un répertoire temporaire dans /var
que dans /tmp où la plupart du temps il se trouve sur le rootdevice.
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
Mauvaise réponse. mktemp crée un fichier temporaire. Rien ne te garantit qu'il est créé dans /tmp.
L'argument à mktemp semble contredire cette affirmation.
Encore une fois, tu ferais bien de sortir du monde Linux ou à la rigueur BSD. J'ai devant moi un système qui 'aliase' le /tmp. Je te laisse chercher lequel. Tu devrais arrêter de sortir péremptoirement des énormités surtout en lisant la page man de Linux ou d'un quelconque BSD. Tout ce que ta ligne signifie, c'est que mktemp va te créer un répertoire qui sera vu comme étant dans /tmp pour le shell. Mais si ça se trouve, ton /tmp n'existe même pas. En l'occurrence, j'ai devant moi un système où cette commande fonctionne alors qu'il n'y a aucun /tmp sur le disque !
J'aimerais aussi que tu regardes très finement ce que fait cette commande et à quoi ressemblent les lignes suivantes. Tu comprendras peut-être en quoi ton assertion est une énormité et pourquoi le flag exec n'est pas nécessaire. Je t'aide, autoconf fait une subtile différence entre les exécutables créés par gcc et les macros d'autoconf et les scripts (awk ou autres) qui sont appelés avec leur interprète sur la ligne de commande.
Je peux te citer au moins deux systèmes Unix où ce n'est pas vrai.
Mais peu importe : quand bien même ce serait vrai, ça veut dire que le répertoire destiné aux fichiers temporaires doit être accessible en exécution pour que configure fonctionne.
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 parfaitement.
Que certains Unix aient eu la lubie de l'appeler autrement que /tmp n'est qu'un bizarrerie historique de plus sans importance.
Définition : est bizarre tout ce que Nicols George ne comprend pas. Il y a une justification au choix qui a été fait sous Solaris. Comme il y a une justification au choix qui a été fait sous d'autres Unix ou d'autres OS. Et ces raisons ne sont pas des bizarreries. Il est d'ailleurs moins idiot d'avoir un répertoire temporaire dans /var que dans /tmp où la plupart du temps il se trouve sur le rootdevice.
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
Bonjour,
Nicolas George :
Où puis-je me renseigner pour savoir ce que la libc est censée écrire dans ce répertoire ?
Dans le code source de la libc si vraiment ça t'intéresse.
Je ne suis pas expert, hein, mais les seuls appels à shm_open() qui apparaisse quand je lance un find sur l'arborescence du code de la lib, sont :
fd = shm_open ("/shm-test", O_RDWR ...
Je suis de moins en moins convaincu de la nocivité de l'écriture dans ce bidule.
Dans ce principe : si on ne sait pas à quoi ça sert, on ne touche pas.
Ce n'est pas un principe, c'est une opinion. De bon aloi sans aucun doute, mais c'est une opinion. Si on en fait un principe, ça s'appelle "le principe de précaution", lequel est auto-contradictoire comme chacun pourra s'en convaincre car si on l'appliquait à lui-même, il ne faudrait pas l'appliquer (C'est pas de moi).
C'est le bon sens le plus élémentaire qui te le dit.
C'est donc ton opinion, pas un impératif. En tous cas, c'est mon opinion. -- Hervé
Bonjour,
Nicolas George :
Où puis-je me renseigner pour savoir ce que la libc
est censée écrire dans ce répertoire ?
Dans le code source de la libc si vraiment ça t'intéresse.
Je ne suis pas expert, hein, mais les seuls appels à shm_open() qui
apparaisse quand je lance un find sur l'arborescence du code de la lib,
sont :
fd = shm_open ("/shm-test", O_RDWR ...
Je suis de moins en moins convaincu de la nocivité de l'écriture dans ce
bidule.
Dans ce principe : si on ne sait pas à quoi ça sert, on ne touche pas.
Ce n'est pas un principe, c'est une opinion. De bon aloi sans aucun
doute, mais c'est une opinion. Si on en fait un principe, ça s'appelle
"le principe de précaution", lequel est auto-contradictoire comme chacun
pourra s'en convaincre car si on l'appliquait à lui-même, il ne faudrait
pas l'appliquer (C'est pas de moi).
C'est le bon sens le plus élémentaire qui te le dit.
C'est donc ton opinion, pas un impératif.
En tous cas, c'est mon opinion.
--
Hervé
Où puis-je me renseigner pour savoir ce que la libc est censée écrire dans ce répertoire ?
Dans le code source de la libc si vraiment ça t'intéresse.
Je ne suis pas expert, hein, mais les seuls appels à shm_open() qui apparaisse quand je lance un find sur l'arborescence du code de la lib, sont :
fd = shm_open ("/shm-test", O_RDWR ...
Je suis de moins en moins convaincu de la nocivité de l'écriture dans ce bidule.
Dans ce principe : si on ne sait pas à quoi ça sert, on ne touche pas.
Ce n'est pas un principe, c'est une opinion. De bon aloi sans aucun doute, mais c'est une opinion. Si on en fait un principe, ça s'appelle "le principe de précaution", lequel est auto-contradictoire comme chacun pourra s'en convaincre car si on l'appliquait à lui-même, il ne faudrait pas l'appliquer (C'est pas de moi).
C'est le bon sens le plus élémentaire qui te le dit.
C'est donc ton opinion, pas un impératif. En tous cas, c'est mon opinion. -- Hervé
Hugues
Ce cher Herve Autret a posté :
Du coup, tu cours le risque d'entrer en conflit avec ce que la libc s'attend à trouver dans ce répertoire, puisque tu modifies son contenu sans passer par les fonctions idoines.
Dit comme ça, ça me paraît relever d'un principe de précaution à la limite de l'excès.
Certainement pas, c'est le B.A.BA de l'informatique, notamment concernant tout ce qui touche au système : quand un truc est prévu pour quelquechose, il vaut mieux éviter de détourner son usage.
(Par expérience, j'ai vu des gens faire des choses qui avaient l'air de fonctionner, alors qu'en réalité ils avaient complètement cassé leur installation. Ils ne s'en sont rendus compte qu'après un reboot malheureux.. Comme quoi, ça ne relève vraiment pas de la paranoïa, mais du bon sens.)
Corollaire : Ce n'est pas parce qu'il est *possible* de faire un truc, qu'il *faut* le faire.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Ce cher Herve Autret <autret@lussinan.org> a posté :
Du coup, tu cours le risque d'entrer en conflit avec ce que la libc
s'attend à trouver dans ce répertoire, puisque tu modifies son contenu
sans passer par les fonctions idoines.
Dit comme ça, ça me paraît relever d'un principe de précaution à la
limite de l'excès.
Certainement pas, c'est le B.A.BA de l'informatique, notamment
concernant tout ce qui touche au système : quand un truc est prévu pour
quelquechose, il vaut mieux éviter de détourner son usage.
(Par expérience, j'ai vu des gens faire des choses qui avaient l'air de
fonctionner, alors qu'en réalité ils avaient complètement cassé leur
installation. Ils ne s'en sont rendus compte qu'après un reboot
malheureux.. Comme quoi, ça ne relève vraiment pas de la paranoïa, mais
du bon sens.)
Corollaire :
Ce n'est pas parce qu'il est *possible* de faire un truc,
qu'il *faut* le faire.
Du coup, tu cours le risque d'entrer en conflit avec ce que la libc s'attend à trouver dans ce répertoire, puisque tu modifies son contenu sans passer par les fonctions idoines.
Dit comme ça, ça me paraît relever d'un principe de précaution à la limite de l'excès.
Certainement pas, c'est le B.A.BA de l'informatique, notamment concernant tout ce qui touche au système : quand un truc est prévu pour quelquechose, il vaut mieux éviter de détourner son usage.
(Par expérience, j'ai vu des gens faire des choses qui avaient l'air de fonctionner, alors qu'en réalité ils avaient complètement cassé leur installation. Ils ne s'en sont rendus compte qu'après un reboot malheureux.. Comme quoi, ça ne relève vraiment pas de la paranoïa, mais du bon sens.)
Corollaire : Ce n'est pas parce qu'il est *possible* de faire un truc, qu'il *faut* le faire.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Hugues
Ce cher Herve Autret a posté :
Bonjour,
Nicolas George :
Où puis-je me renseigner pour savoir ce que la libc est censée écrire dans ce répertoire ?
Dans le code source de la libc si vraiment ça t'intéresse.
Je ne suis pas expert, hein, mais les seuls appels à shm_open() qui apparaisse quand je lance un find sur l'arborescence du code de la lib, sont :
fd = shm_open ("/shm-test", O_RDWR ...
Je suis de moins en moins convaincu de la nocivité de l'écriture dans ce bidule.
Peut être que le jour où tu utiliseras, sans le savoir, une application qui fait de nombreux appels à shm_open(), tu auras des problèmes :-)
Je ne parle pas de la probabilité, mais de prendre des bonnes habitudes dès que tu le peux. En l'occurence, tu peux déjà commencer par éviter d'écrire n'importe quoi n'importe où :-)
Dans ce principe : si on ne sait pas à quoi ça sert, on ne touche pas.
Ce n'est pas un principe, c'est une opinion.
Si, c'est un principe, et de base.
Sauf si tu travailles sur une machine de bidouillage, auquel cas tu peux évidemment faire ce que tu veux dessus..
De bon aloi sans aucun doute, mais c'est une opinion. Si on en fait un principe, ça s'appelle "le principe de précaution",
Non, le principe de précaution, c'est "je touche surtout à rien".
Le principe dont on te parle c'est : "renseigne-toi avant de faire n'importe quoi". :)
C'est le bon sens le plus élémentaire qui te le dit.
C'est donc ton opinion, pas un impératif. En tous cas, c'est mon opinion.
Moi, j'aime bien les oignons. ;-)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Ce cher Herve Autret <autret@lussinan.org> a posté :
Bonjour,
Nicolas George :
Où puis-je me renseigner pour savoir ce que la libc
est censée écrire dans ce répertoire ?
Dans le code source de la libc si vraiment ça t'intéresse.
Je ne suis pas expert, hein, mais les seuls appels à shm_open() qui
apparaisse quand je lance un find sur l'arborescence du code de la lib,
sont :
fd = shm_open ("/shm-test", O_RDWR ...
Je suis de moins en moins convaincu de la nocivité de l'écriture dans ce
bidule.
Peut être que le jour où tu utiliseras, sans le savoir, une application
qui fait de nombreux appels à shm_open(), tu auras des problèmes :-)
Je ne parle pas de la probabilité, mais de prendre des bonnes habitudes
dès que tu le peux. En l'occurence, tu peux déjà commencer par éviter
d'écrire n'importe quoi n'importe où :-)
Dans ce principe : si on ne sait pas à quoi ça sert, on ne touche pas.
Ce n'est pas un principe, c'est une opinion.
Si, c'est un principe, et de base.
Sauf si tu travailles sur une machine de bidouillage, auquel cas tu peux
évidemment faire ce que tu veux dessus..
De bon aloi sans aucun doute, mais c'est une opinion. Si on en fait un
principe, ça s'appelle "le principe de précaution",
Non, le principe de précaution, c'est "je touche surtout à rien".
Le principe dont on te parle c'est : "renseigne-toi avant de faire
n'importe quoi". :)
C'est le bon sens le plus élémentaire qui te le dit.
C'est donc ton opinion, pas un impératif.
En tous cas, c'est mon opinion.
Où puis-je me renseigner pour savoir ce que la libc est censée écrire dans ce répertoire ?
Dans le code source de la libc si vraiment ça t'intéresse.
Je ne suis pas expert, hein, mais les seuls appels à shm_open() qui apparaisse quand je lance un find sur l'arborescence du code de la lib, sont :
fd = shm_open ("/shm-test", O_RDWR ...
Je suis de moins en moins convaincu de la nocivité de l'écriture dans ce bidule.
Peut être que le jour où tu utiliseras, sans le savoir, une application qui fait de nombreux appels à shm_open(), tu auras des problèmes :-)
Je ne parle pas de la probabilité, mais de prendre des bonnes habitudes dès que tu le peux. En l'occurence, tu peux déjà commencer par éviter d'écrire n'importe quoi n'importe où :-)
Dans ce principe : si on ne sait pas à quoi ça sert, on ne touche pas.
Ce n'est pas un principe, c'est une opinion.
Si, c'est un principe, et de base.
Sauf si tu travailles sur une machine de bidouillage, auquel cas tu peux évidemment faire ce que tu veux dessus..
De bon aloi sans aucun doute, mais c'est une opinion. Si on en fait un principe, ça s'appelle "le principe de précaution",
Non, le principe de précaution, c'est "je touche surtout à rien".
Le principe dont on te parle c'est : "renseigne-toi avant de faire n'importe quoi". :)
C'est le bon sens le plus élémentaire qui te le dit.
C'est donc ton opinion, pas un impératif. En tous cas, c'est mon opinion.
Moi, j'aime bien les oignons. ;-)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Herve Autret
Bonjour,
Hugues :
concernant tout ce qui touche au système : quand un truc est prévu pour quelquechose, il vaut mieux éviter de détourner son usage.
... sans précautions. Le faire sur un système spécial bidouille comme tu dis, par exemple. Ceci dit, le fait que /dev/shm soit _réservé_ à la libc n'est pas avéré pour moi. C'est le bon sens, selon toi et Nicolas, point.
Si je veux monitorer le contenu de mon /dev/shm, je peux faire un ls toutes les X secondes et n'enregistrer le résultat que s'il diffère du précédent. Qu'y aurait-il comme moyen plus propre ?
(Par expérience, j'ai vu des gens faire des choses qui avaient [] complètement cassé leur installation.
Hm .. On se connaît ? ;-)
Corollaire : Ce n'est pas parce qu'il est *possible* de faire un truc, qu'il *faut* le faire.
Contraposition (ou contre-pied ? je ne suis pas trop culturé) : Parmi les trucs qu'on peut faire, il y en a qu'on peut faire sans risque. Certes, mais tant je ne sais pas distinguer les trucs nocifs des autres, je ne suis pas plus avancé.
à + -- Hervé
Bonjour,
Hugues :
concernant tout ce qui touche au système : quand un truc est prévu pour
quelquechose, il vaut mieux éviter de détourner son usage.
... sans précautions. Le faire sur un système spécial bidouille comme tu
dis, par exemple. Ceci dit, le fait que /dev/shm soit _réservé_ à la libc
n'est pas avéré pour moi. C'est le bon sens, selon toi et Nicolas, point.
Si je veux monitorer le contenu de mon /dev/shm, je peux faire un ls
toutes les X secondes et n'enregistrer le résultat que s'il diffère du
précédent. Qu'y aurait-il comme moyen plus propre ?
(Par expérience, j'ai vu des gens faire des choses qui avaient []
complètement cassé leur installation.
Hm .. On se connaît ? ;-)
Corollaire :
Ce n'est pas parce qu'il est *possible* de faire un truc, qu'il *faut*
le faire.
Contraposition (ou contre-pied ? je ne suis pas trop culturé) :
Parmi les trucs qu'on peut faire, il y en a qu'on peut faire sans
risque. Certes, mais tant je ne sais pas distinguer les trucs nocifs des
autres, je ne suis pas plus avancé.
concernant tout ce qui touche au système : quand un truc est prévu pour quelquechose, il vaut mieux éviter de détourner son usage.
... sans précautions. Le faire sur un système spécial bidouille comme tu dis, par exemple. Ceci dit, le fait que /dev/shm soit _réservé_ à la libc n'est pas avéré pour moi. C'est le bon sens, selon toi et Nicolas, point.
Si je veux monitorer le contenu de mon /dev/shm, je peux faire un ls toutes les X secondes et n'enregistrer le résultat que s'il diffère du précédent. Qu'y aurait-il comme moyen plus propre ?
(Par expérience, j'ai vu des gens faire des choses qui avaient [] complètement cassé leur installation.
Hm .. On se connaît ? ;-)
Corollaire : Ce n'est pas parce qu'il est *possible* de faire un truc, qu'il *faut* le faire.
Contraposition (ou contre-pied ? je ne suis pas trop culturé) : Parmi les trucs qu'on peut faire, il y en a qu'on peut faire sans risque. Certes, mais tant je ne sais pas distinguer les trucs nocifs des autres, je ne suis pas plus avancé.
