• # Place d'Hasard par rapport à GSL, OpenSSL & cie

    Posté par (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 10.

    (rah merde, j'ai posté mon journal alors que je voulais faire une prévisualisation... tant pis, le texte était presque terminé)

    Comme Hasard 0.8 peut maintenant se « brancher » sur OpenSSL et gcrypt, une application qui a des besoins cryptographiques peut utiliser Hasard pour s'abstraire de la bibliothèque sous-jacente : utilisez OpenSSL ou gcrypt, selon vos envies ou vos contraintes (ex: licence).

    Pour GSL par contre, je pense qu'il faudrait que ça soit l'inverse : GSL devrait réutiliser Hasard pour générer la graine des différents algorithmes, voir peut-être aussi pour gsl_rng_uniform_int() et gsl_rng_uniform(). Actuellement, GSL n'offre aucun moyen d'initialiser la graine d'un algorithme :-/

    Hasard pourrait aussi être utilisé directement dans les applications ou dans un langage de programme. Il serait utile à pwgen par exemple (qui utilise /dev/urandom ou drand48 actuellement).

    Les générateurs gmp_mt et glib d'Hasard me servent à tester Hasard et à tester les bibliothèques GMP et glib.

    --

    Comme l'indique son numéro de version (0.8 : 80%), Hasard n'est pas encore terminé et l'API risque encore de changer avant la version 1.0. Il est fort probable que l'API hasard_double() change car elle pose des problèmes pour l'intégration des autres bibliothèques.