<foo> simply produces <foo>in the text).
<URL: http://somewhere.tld/ >,
and it will be automatically made into a link.
(Do not try any other way or it might count as an attempt to spam.)mailto: URI,
e.g. mailto:my.email@somewhere.tld,
if you do not have a genuine Web site).
Anonymous Coward #880 (Wkfauna) (2004-05-14T15:54:23Z)
If you can actually detect errors with your program, you might want to publish the method. It reminds me a bit of fuzz testing (
<URL: http://www.cs.wisc.edu/~bart/fuzz/fuzz.html >)
Ruxor (2004-05-14T09:09:16Z)
Je pensais en effet surtout aux problèmes mémoire, qui sont ma bête noire habituelle. Il y a moyen, sous Linux, de demander au noyau de ne pas allouer normalement certaines pages mémoire, et d'y accéder ensuite directement via /dev/mem pour y écrire ou y lire des choses. J'avais déjà, par le passé, fait des tests intensifs de mémoire de ce type et découvert des bits défectueux. Les problèmes CPU peuvent être de millions de sortes différentes : je ne parierais pas qu'il ne peut pas s'en produire qui peuvent être détectés par ce truc (notamment des problèmes qui se produiraient en cas de surchauffe). Il faut aussi penser aux problèmes dans les bus de la carte mère (les rayons cosmiques qui frappent le bus et qui corrompent un bit, ce n'est pas qu'une légende). Par ailleurs, n'oublions pas qu'il peut exister des problèmes logiciels, genre, des race conditions particulièrement subtiles dans des systèmes SMP qui font que le filesystem va oublier d'écrire un bout du fichier ou que le swap va mal swapper : c'est ce que je soupçonne dans mon cas particulier.
Pourquoi RC4 ? Parce que c'est facile à coder. Les congruences linéaires on n'ose même pas appeler ça des nombres aléatoires (et d'ailleurs je ne suis pas pleinement convaincu que ça soit plus efficace que RC4 vu que ce dernier ne fait que des additions et des swaps et que l'état est assez petit pour tenir entièrement en cache). Quant à Mersenne Twister, il est plus pénible à programmer, et s'il est peut-être statistiquement meilleur que RC4, il est cryptographiquement beaucoup plus mauvais, donc, même si ce n'était pas le but, bof.
Pascal (2004-05-14T08:38:45Z)
Je ne connais pas bien les entrailles de Linux, mais je reste sceptique quant à la probabilité que ce genre de test ne détecte beaucoup d'erreurs. Au niveau CPU, les instructions utilisées sont assez peu nombreuses et n'ont rien de particulier ; autrement dit, je pense que si le CPU était défectueux au point de provoquer une erreur dans l'exécution de ce programme, l'OS ne démarrait même pas. Au niveau disque, il existe des codes correcteurs d'erreur dans le hard qui font que les erreurs sont soit automatiquement corrigées et passent inaperçues, soit rapportées au système (certains OS logguent alors une entrée dans un journal, mais je ne sais pas ce que fait Linux). Par ailleurs, ce test ne peut vérifier que les secteurs du disque encore inutilisés : impossible de savoir si la partition de swap est défectueuse, ou si un fichier système rarement utilisé est corrompu, par exemple.
Pour tester la RAM, en revanche, ça peut donner une indication, mais c'est assez hasardeux : à moins de tourner sous un OS minimaliste qui n'a pas de memory manager, rien ne garantit que les opérations sont réllement effectuées en RAM ; elle peuvent tout aussi bien être effectuées sur disque. Je pense qu'un test plus efficace serait de faire un malloc géant d'une taille proche de la RAM disponible, et de faire des accès aléatoires bien répartis dans tout ce bloc pour augmenter le working set du process et empêcher ainsi le système d'utiliser le swap.
Enfin ça n'est que mon avis, je me trompe peut-être lourdement.
Sinon, pourquoi ARC4 en particulier ? Il existe des générateurs aléatoires bien plus simple à coder (genre congruence linéaire si tu privilégies l'efficacité) ou bien plus rigolo à coder (genre Mersenne Twister si tu privilégies le fun)…