000297b0 10 8b 45 f4 f6 c4 02 74 12 83 c4 f8 8b 55 f8 52
000297b0 10 8b 45 f4 f6 c4 02 74 12 83 c4 f8 8b 55 f8 52
000297b0 10 8b 45 f4 f6 c4 02 74 12 83 c4 f8 8b 55 f8 52
Bonjour à tous
Toujours dans le cadre de surveillance de machines, pour la 3ième fois
en 6 mois et deuxième fois en quinze jours, je viens de constater
l'inversion d'un bit (le passage de 1 à 0) sur un fichier
(/usr/bin/emacs-20.7) sur une machine:
Bonjour à tous
Toujours dans le cadre de surveillance de machines, pour la 3ième fois
en 6 mois et deuxième fois en quinze jours, je viens de constater
l'inversion d'un bit (le passage de 1 à 0) sur un fichier
(/usr/bin/emacs-20.7) sur une machine:
Bonjour à tous
Toujours dans le cadre de surveillance de machines, pour la 3ième fois
en 6 mois et deuxième fois en quinze jours, je viens de constater
l'inversion d'un bit (le passage de 1 à 0) sur un fichier
(/usr/bin/emacs-20.7) sur une machine:
Bonjour à tous
[...]
C'est donc la 3ième fois, sur 3 machines distinctes dont une très
récente, dans 3 lieux différents, sans que smartmontoools me rapporte un
incident quelconque et avec des fichiers non utilisés sur le moment et
en lecture seule. A noter que le emacs modifié marche parfaitement. Je
renouvelle donc ma question: suis je le seul à constater ce genre de
phénomène et quelqu'un a-t-il une idée sur leur fréquence?
Bonne journée à tous
François Boisson
Bonjour à tous
[...]
C'est donc la 3ième fois, sur 3 machines distinctes dont une très
récente, dans 3 lieux différents, sans que smartmontoools me rapporte un
incident quelconque et avec des fichiers non utilisés sur le moment et
en lecture seule. A noter que le emacs modifié marche parfaitement. Je
renouvelle donc ma question: suis je le seul à constater ce genre de
phénomène et quelqu'un a-t-il une idée sur leur fréquence?
Bonne journée à tous
François Boisson
Bonjour à tous
[...]
C'est donc la 3ième fois, sur 3 machines distinctes dont une très
récente, dans 3 lieux différents, sans que smartmontoools me rapporte un
incident quelconque et avec des fichiers non utilisés sur le moment et
en lecture seule. A noter que le emacs modifié marche parfaitement. Je
renouvelle donc ma question: suis je le seul à constater ce genre de
phénomène et quelqu'un a-t-il une idée sur leur fréquence?
Bonne journée à tous
François Boisson
Le 13/07/05, François Boisson a
écrit :
> Bonjour à tous
>
> Toujours dans le cadre de surveillance de machines, pour la 3ième
> fois en 6 mois et deuxième fois en quinze jours, je viens de
> constater l'inversion d'un bit (le passage de 1 à 0) sur un fichier
> (/usr/bin/emacs-20.7) sur une machine:
J'avoue que je n'ai jamais vérifié sur mes machines mais cela ne me
choque pas outre mesure. Statistiquement parlant, si tu n'as pas de
matériel très haut de gamme (avec multiples codes de corrections
d'erreurs), ce genre d'erreurs, certainement provoqué par des
perturbations électromagnétiques extérieures, sera de plus en plus
fréquent à l'avenir...
Pour info, le gap pour faire passer un électron d'un état à un autre
sur les substrats de silicium se réduit comme peau de chagrin avec la
diminution des tailles de grille de transistor... en gros, pour
simplifier, la sensibilité à des phénomènes extérieurs va croissant
avec l'augmentation de performance de nos systèmes...
Le 13/07/05, François Boisson<user.anti-spam@maison.homelinux.net> a
écrit :
> Bonjour à tous
>
> Toujours dans le cadre de surveillance de machines, pour la 3ième
> fois en 6 mois et deuxième fois en quinze jours, je viens de
> constater l'inversion d'un bit (le passage de 1 à 0) sur un fichier
> (/usr/bin/emacs-20.7) sur une machine:
J'avoue que je n'ai jamais vérifié sur mes machines mais cela ne me
choque pas outre mesure. Statistiquement parlant, si tu n'as pas de
matériel très haut de gamme (avec multiples codes de corrections
d'erreurs), ce genre d'erreurs, certainement provoqué par des
perturbations électromagnétiques extérieures, sera de plus en plus
fréquent à l'avenir...
Pour info, le gap pour faire passer un électron d'un état à un autre
sur les substrats de silicium se réduit comme peau de chagrin avec la
diminution des tailles de grille de transistor... en gros, pour
simplifier, la sensibilité à des phénomènes extérieurs va croissant
avec l'augmentation de performance de nos systèmes...
Le 13/07/05, François Boisson a
écrit :
> Bonjour à tous
>
> Toujours dans le cadre de surveillance de machines, pour la 3ième
> fois en 6 mois et deuxième fois en quinze jours, je viens de
> constater l'inversion d'un bit (le passage de 1 à 0) sur un fichier
> (/usr/bin/emacs-20.7) sur une machine:
J'avoue que je n'ai jamais vérifié sur mes machines mais cela ne me
choque pas outre mesure. Statistiquement parlant, si tu n'as pas de
matériel très haut de gamme (avec multiples codes de corrections
d'erreurs), ce genre d'erreurs, certainement provoqué par des
perturbations électromagnétiques extérieures, sera de plus en plus
fréquent à l'avenir...
Pour info, le gap pour faire passer un électron d'un état à un autre
sur les substrats de silicium se réduit comme peau de chagrin avec la
diminution des tailles de grille de transistor... en gros, pour
simplifier, la sensibilité à des phénomènes extérieurs va croissant
avec l'augmentation de performance de nos systèmes...
Plus sérieusement, ne serait-ce pas le classique pb du facteur humain
?
Est-ce les progs qui se modifient pour une raison lambda, ou bien toi
qui ai l'impréssion qu'ils se modifient ?
ta backup est -elle vraiment fiable ?
C'est pt elle aussi qui n'est pas correcte !
Je te suggère de comparer ton programme xyz (ici emacs) avec un totu
beau tout neuf provenant d'une source sûre et de faire de même avec la
sauvegarde de référence.
Plus sérieusement, ne serait-ce pas le classique pb du facteur humain
?
Est-ce les progs qui se modifient pour une raison lambda, ou bien toi
qui ai l'impréssion qu'ils se modifient ?
ta backup est -elle vraiment fiable ?
C'est pt elle aussi qui n'est pas correcte !
Je te suggère de comparer ton programme xyz (ici emacs) avec un totu
beau tout neuf provenant d'une source sûre et de faire de même avec la
sauvegarde de référence.
Plus sérieusement, ne serait-ce pas le classique pb du facteur humain
?
Est-ce les progs qui se modifient pour une raison lambda, ou bien toi
qui ai l'impréssion qu'ils se modifient ?
ta backup est -elle vraiment fiable ?
C'est pt elle aussi qui n'est pas correcte !
Je te suggère de comparer ton programme xyz (ici emacs) avec un totu
beau tout neuf provenant d'une source sûre et de faire de même avec la
sauvegarde de référence.
Le 13/07/05, François Boisson a écrit :Bonjour à tous
Toujours dans le cadre de surveillance de machines, pour la 3ième fois
en 6 mois et deuxième fois en quinze jours, je viens de constater
l'inversion d'un bit (le passage de 1 à 0) sur un fichier
(/usr/bin/emacs-20.7) sur une machine:
J'avoue que je n'ai jamais vérifié sur mes machines mais cela ne me
choque pas outre mesure. Statistiquement parlant, si tu n'as pas de
matériel très haut de gamme (avec multiples codes de corrections
d'erreurs), ce genre d'erreurs, certainement provoqué par des
perturbations électromagnétiques extérieures, sera de plus en plus
fréquent à l'avenir...
Pour info, le gap pour faire passer un électron d'un état à un autre
sur les substrats de silicium se réduit comme peau de chagrin avec la
diminution des tailles de grille de transistor... en gros, pour
simplifier, la sensibilité à des phénomènes extérieurs va croissant
avec l'augmentation de performance de nos systèmes...
PK
Le 13/07/05, François Boisson<user.anti-spam@maison.homelinux.net> a écrit :
Bonjour à tous
Toujours dans le cadre de surveillance de machines, pour la 3ième fois
en 6 mois et deuxième fois en quinze jours, je viens de constater
l'inversion d'un bit (le passage de 1 à 0) sur un fichier
(/usr/bin/emacs-20.7) sur une machine:
J'avoue que je n'ai jamais vérifié sur mes machines mais cela ne me
choque pas outre mesure. Statistiquement parlant, si tu n'as pas de
matériel très haut de gamme (avec multiples codes de corrections
d'erreurs), ce genre d'erreurs, certainement provoqué par des
perturbations électromagnétiques extérieures, sera de plus en plus
fréquent à l'avenir...
Pour info, le gap pour faire passer un électron d'un état à un autre
sur les substrats de silicium se réduit comme peau de chagrin avec la
diminution des tailles de grille de transistor... en gros, pour
simplifier, la sensibilité à des phénomènes extérieurs va croissant
avec l'augmentation de performance de nos systèmes...
PK
Le 13/07/05, François Boisson a écrit :Bonjour à tous
Toujours dans le cadre de surveillance de machines, pour la 3ième fois
en 6 mois et deuxième fois en quinze jours, je viens de constater
l'inversion d'un bit (le passage de 1 à 0) sur un fichier
(/usr/bin/emacs-20.7) sur une machine:
J'avoue que je n'ai jamais vérifié sur mes machines mais cela ne me
choque pas outre mesure. Statistiquement parlant, si tu n'as pas de
matériel très haut de gamme (avec multiples codes de corrections
d'erreurs), ce genre d'erreurs, certainement provoqué par des
perturbations électromagnétiques extérieures, sera de plus en plus
fréquent à l'avenir...
Pour info, le gap pour faire passer un électron d'un état à un autre
sur les substrats de silicium se réduit comme peau de chagrin avec la
diminution des tailles de grille de transistor... en gros, pour
simplifier, la sensibilité à des phénomènes extérieurs va croissant
avec l'augmentation de performance de nos systèmes...
PK
> Déjà fait, les 3 fois. Je suis certain de ce que j'avance ici.
> Déjà fait, les 3 fois. Je suis certain de ce que j'avance ici.
> Déjà fait, les 3 fois. Je suis certain de ce que j'avance ici.
Je ne suis pas trop convaincu par ton explication. Si les machines
perdaient leur fiabilité à ce point, peu de gens arriveraient à
avoir des systèmes stables. On ne peut pas envisager que régulièrement
un bit change dans un executable ou dans un librairie comme cela.
Je ne sais pas combien de machines administre François mais la
fréquence me parait anormalement élevée.
De plus François a détecté une modification sur son disque, les
transistors ne rentrent donc pas en jeu, même si un phénomène
équivalent doit exister au niveau du disque.
Si ton explication se révelait correcte, cela signifierait aussi
que tous ceux qui ont des PCs de base devraient se soucier de ce genre
de problèmes, il existerait des solutions toutes faites il me semble,
or apparemment ce n'est pas le cas ?
Ou alors les disques en cause sont tous du même modèle et présentent
un problème de fabrication ?
Je ne suis pas trop convaincu par ton explication. Si les machines
perdaient leur fiabilité à ce point, peu de gens arriveraient à
avoir des systèmes stables. On ne peut pas envisager que régulièrement
un bit change dans un executable ou dans un librairie comme cela.
Je ne sais pas combien de machines administre François mais la
fréquence me parait anormalement élevée.
De plus François a détecté une modification sur son disque, les
transistors ne rentrent donc pas en jeu, même si un phénomène
équivalent doit exister au niveau du disque.
Si ton explication se révelait correcte, cela signifierait aussi
que tous ceux qui ont des PCs de base devraient se soucier de ce genre
de problèmes, il existerait des solutions toutes faites il me semble,
or apparemment ce n'est pas le cas ?
Ou alors les disques en cause sont tous du même modèle et présentent
un problème de fabrication ?
Je ne suis pas trop convaincu par ton explication. Si les machines
perdaient leur fiabilité à ce point, peu de gens arriveraient à
avoir des systèmes stables. On ne peut pas envisager que régulièrement
un bit change dans un executable ou dans un librairie comme cela.
Je ne sais pas combien de machines administre François mais la
fréquence me parait anormalement élevée.
De plus François a détecté une modification sur son disque, les
transistors ne rentrent donc pas en jeu, même si un phénomène
équivalent doit exister au niveau du disque.
Si ton explication se révelait correcte, cela signifierait aussi
que tous ceux qui ont des PCs de base devraient se soucier de ce genre
de problèmes, il existerait des solutions toutes faites il me semble,
or apparemment ce n'est pas le cas ?
Ou alors les disques en cause sont tous du même modèle et présentent
un problème de fabrication ?
> Déjà fait, les 3 fois. Je suis certain de ce que j'avance ici.
Pour lever toute ambiguité, je suppose que ton test est passé un
certain nombre de fois, qu'il continue à passer sur un certain
nombre de machines et que au bout d'un moment il ne passe plus
sur certaines machines ?
Le backup est-il partagé entre les différentes machines que tu
surveilles ?
> Déjà fait, les 3 fois. Je suis certain de ce que j'avance ici.
Pour lever toute ambiguité, je suppose que ton test est passé un
certain nombre de fois, qu'il continue à passer sur un certain
nombre de machines et que au bout d'un moment il ne passe plus
sur certaines machines ?
Le backup est-il partagé entre les différentes machines que tu
surveilles ?
> Déjà fait, les 3 fois. Je suis certain de ce que j'avance ici.
Pour lever toute ambiguité, je suppose que ton test est passé un
certain nombre de fois, qu'il continue à passer sur un certain
nombre de machines et que au bout d'un moment il ne passe plus
sur certaines machines ?
Le backup est-il partagé entre les différentes machines que tu
surveilles ?