Bon sinon à part faire un interpréteur qui a besoin de 4Go de ram pour fonctionner et qui rendent python encore plus lent : ça apporte quoi ?
Jython permet d'utiliser des modules et classes Java en Python, et inversement. Disons qu'en entreprise, on a pas toujours le choix des outils. Parfois la JVM est imposée. Et là ça permet de quand même faire du Python :-)
Quand aux performances ou à la gestion mémoire, je ne sais pas trop. Mais j'aurai tendance à penser que vu la qualité de la JVM Sun, ça doit aller vite (compilateur JIT) et utiliser correctement la mémoire. On peut configurer finement comment JVM utilise la mémoire.
je me demande si ce n'est pas une fête pour les cyber-'patriotes' chinois
Pourquoi est-ce que seuls des chinois exploiteraient les failles ? Pourquoi pas, par exemple, un ennemi de la Chine ? Les opposants au régime par exemple. Un troyan qui installerait Freenet partout (en mode opennet), ça serait un sacré pied de nez au gouvernement ;-)
J'ai bossé une grosse soirée sur la dépêche eglibc, et je suis content d'être récompensé par un abonnement à Linux Mag. Merci à linuxfr et à ses partenaires.
Et bien sûr : proposez vos dépêches si vous voulez vous aussi recevoir des cadeaux ! Ça coûte juste un peu de temps ;-)
Dans la liste des avantages cités, je ne vois que 2 choses dont je pourrais bénéficier: le check plus rapide, et les sommes de contrôle.
Les extends sont très bénéfiques en vitesse de lectures de gros fichiers (un avi de 650 Mo ? non, une ISO Debian de 5 Go bien sûr !). Je pense qu'ils sont également bénéfiques en vitesse d'écriture (pour les disques utilisant des têtes de lecture, car ext4 en limite le déplacement).
Merci pour tes précisions, je ne suis que Freenet de loin, mes infos sont donc peu fiables :-)
Sinon une ou plusieurs couches de transport stéganographiques sont prévues à terme (version 0.9 si je ne m'abuse).
Euh, oui, un ami (développeur Freenet) m'en parlait déjà y'a 2/3 ans, mais en pratique il n'y a toujours rien d'implémenté.
Enfin quant à trouver si quelqu'un utilise Freenet, c'est tout à fait possible en créant beaucoup de noeuds s'il est connecté à l'opennet
Je pensais plus à du flicage fait par l'État qui peut se permettre de rajouter des sondes chez les FAI. La censeurs (ça existe ce mot ? personne qui censure) sont souvent haut placés et ont des moyens.
Et quand bien même il utilise Freenet, le trafic est lissé de sorte à ne pas laisser déceler une éventuelle insertion
Oui, je disais juste que si on peut sniffer la connexion d'un internaute, on peut savoir s'il utilise Freenet ou pas. Tout ça pour dire que je doute que Freenet aide dans les pays où Internet est fortement censuré et surveillé de près.
Après, bien sûr que Freenet est un chouette projet. Il peut servir à pas mal de choses, et j'espère qu'il sera utilisé pour de bonnes choses (comme la liberté d'expression).
Je pense que vu que Freenet chiffre dans tous les sens, ce n'est pas trop gênant d'utiliser un OS propriétaire. Le cache est par exemple chiffré : il n'est pas possible de savoir ce qui est stocké dans le cache. Par contre, si la machine est verrolée (ex: troyan), forcément l'attaquant saura quels sites sont consultés (ex: envoyer une capture d'écran), qu'importe le niveau de chiffrement.
D'ailleurs, Freenet vise (entre autres) les chinois qui sont (je pense) majoritairement sous Windows. Un chinois qui utilise Linux, à mon avis il est directement vu comme un mec louche...
D'ailleurs, j'avais regardé un peu Freenet et je trouve qu'il n'a rien de discret :
* Il utilise des ports TCP non conventionnels
* Les paquets sont entièrement chiffrés et ça se remarque facilement (ex: mesurer l'entropie des paquets)
* Fonctionnement P2P : envoie beaucoup de données, alors qu'un internaute qui surfe sur des sites web (en HTTP) émet peu de données
Je veux dire qu'une personne qui peut sniffer une connexion Internet (possible si on a accès aux routeurs des FAI, ce qui est le cas pour un état, tout particulièrement en Chine) n'aura pas de mal à remarquer que l'internaute utilise Freenet. Et vu la faible popularité de Freenet, un mec qui l'utilise est forcément louche...
Fedora 11, qui vient de sortir, intègre KMS pour AMD (Ati), Intel et Nouveau (Nvidia). Par contre, c'est désactivé par défaut, seul les Radeon R300 et plus récents l'ont pas défaut.
Details: The infrastructure is all in place. The driver details are as follows: For AMD/ATI hardware, R300 and newer has KMS enabled by default; R100-R200 does not yet have 3D support with KMS, so is default to disabled (this has been targeted for Fedora 11). For Intel hardware, we default to disabled (targeted for Fedora 11). http://fedoraproject.org/wiki/Features/KernelModesetting
Il faudrait que les constructeurs de mémoire, ou ceux de cartes-mères, mettent en place un mécanisme de purge de la mémoire lors de l'arrêt de la machine.
Je pense que tu peux faire une attaque coldboot avec la machine en fonctionnement (extraire la barrette de mémoire alors que l'ordinateur tourne toujours). Si ton objectif est de lire le disque dur, tu peux débrancher le disque dur, arracher la mémoire (bon, pas sûr qu'elle soit contente), récupérer la clé (en mémoire) du disque dur, puis brancher le disque dur sur un autre ordinateur sain.
Il existe un projet visant à ne pas stocker les clés privées en mémoire : les clés ne seraient que présentes dans le cache du processeur (cache L1 je pense). Bon, après il doit être possible de lire la mémoire du CPU. Tout dépend des moyens qu'on se donne. Des ingénieurs d'IBM ont bien réussi à écrire dans le cache L1 d'un CPU avec un laser, et des hackers ont réussi à lire des clés de chiffrement Xbox en lisant ce qui passe sur le port PCI (je me souviens plus des détails) :-) http://frozencache.blogspot.com/
Il faut savoir que patrick_g est harcelé toutes les heures par les modérateurs parce qu'il propose ses dépêches avant la sortie officielle de la nouvelle version de Linux. Il avait proposé une dépêche sur GCC 4.4 qui est restée plusieurs mois dans la liste des dépêches à modérer, et du coup il arrête pas de se faire chambrer sur ça :-)
La crise joue, d'une certaine manière, en faveur de [PHP]. « Les cycles de développement sont plus courts et moins coûteux. La plus forte croissance de développeurs PHP provient aujourd'hui des entreprises et des sociétés de services, alors qu'initialement ce langage était porté par des développeurs indépendants. Par ailleurs, c'est un langage qui permet maintenant de créer des applications de bout en bout. Des PGI comme Kelia ou Open ERP sont entièrement développés en PHP », ajoute Christian Durel.
Bien sûr, l'auteur de l'article a vérifié la véracité des informations avant de poster :-) Bon et puis c'est pas comme si les journalistes modifiaient des fois le texte d'une citation avant de publier un article...
Article intéressant à ce sujet : faut-il accepter de passer à la télévision si la conclusion est écrite d'avance ? http://sid.rstack.org/blog/index.php/345-les-marches-de-la-g(...)
(c'était au sujet d'un reportage fait à l'arrache sur la sécurité informatique)
Vu la quantité de failles de sécurité qui pleuvent sur PHP, je trouve que ça fait pas très sérieux de continuer à l'utiliser / le proposer : « À gagner : Un hébergement de 2 ans, supportant PHP4, PHP5, MySQL. »
Bon et PHP6 alors, c'est mort ? C'est comme Perl6. Y'a ceux qui parlent (PHP6/Perl6 c'est super, ça tue tout, blablabla), et ceux qui codent (Python3 sorti fin 2008).
Je préfère attendre la prochaine version, voir la version 1.0. À vrai dire, j'aimerai qu'Hasard soit utilisé par une vraie application pour pouvoir peaufiner (et corriger) l'API avant de faire une grosse campagne de buzz :-)
faudrait aussi faire des binding python/perl/php & co ... yaka fokon ;)
Il y a déjà un binding Python. Je ne connais pas assez bien Perl et PHP pour écrire un binding pour ces langages. L'idéal serait qu'Hasard soit utilisé par Python, Perl, PHP & cie pour leur fonction "rand" :-)
J'avais d'abord utilisé des nombres flottants, mais cette solution est bancale. Elle fonctionne à peu près sur un entier de 32 bits et un flottant de 64 bits. Mais avec des entiers de 64 bits (type long sur une machine x86_64), la conversion vers/depuis les flottants fait perdre les bits de poids faible et est donc largement biaisée.
C'est justement pour éviter que chacun recode sa fonction randrange(a,b), un peu biaisée voir complètement fausse, que j'ai codé Hasard.
La fonction hasard_engine_ulong() a subi de nombreuses réécritures et corrections :
* Hasard 0.1 : utilisation des flottants mais avec un arrondi foireux, les bornes (min/max) étaient 2x moins fréquentes :-/
* Hasard 0.3 : correction pour les bornes
* Hasard 0.4 : support des générateurs dont l'intervalle de sortie est plus petit que celui demandé par l'utilisateur
* Hasard 0.5 : réécriture de l'algorithme, utilise GMP et uniquement des nombres entiers (pour supporter les CPU 64 bits)
* Hasard 0.6 : réécriture de l'algorithme, basé sur celui de GSL, pour se passer de GMP (pour limiter les dépendances)
Je pense que l'algorithme actuel est bon. Il reste juste à gérer un dernier cas : quand ULONG+1 n'est pas un multiple de l'intervalle de sortie du générateur (cas rare, arrive pour certains générateurs peu utilisés et déconseillés).
Disons que l'intervalle de sortie du générateur soit [a; b] et celui que veut l'utilisateur est [x; y]. On peut utiliser le modulo à condition que :
* [a; b] soit plus grand (ou de même taille) que [x; y] : (b-a+1) >= (y-x+1)
* (b-a+1) soit multiple de (y-x+1)
Exemple : générateur : [0; 99] (100 nombres), utilisateur : [0; 9]. Si le générateur est uniforme, rand() % 10 sera aussi uniforme.
--
Hasard réutilise l'idée de l'algorithme de GSL, mais tire plusieurs nombres si l'intervalle du générateur est plus petit que celui de l'utilisateur. L'algorithme général est :
1. tirer un nombre au hasard
2. diviser ce nombre par un facteur (pour limiter le nombre d'itérations)
3. si le nombre est plus grand que ce que veut l'utilisateur, recommencer (retour en 1.)
(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.
# L'OS à moëlle
Posté par Victor STINNER (site web personnel) . En réponse au journal Test Mandriva par ZDNet : waouh !. Évalué à 9.
Ils recouvrent aussi les muscles ?
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 6.
Jython permet d'utiliser des modules et classes Java en Python, et inversement. Disons qu'en entreprise, on a pas toujours le choix des outils. Parfois la JVM est imposée. Et là ça permet de quand même faire du Python :-)
Quand aux performances ou à la gestion mémoire, je ne sais pas trop. Mais j'aurai tendance à penser que vu la qualité de la JVM Sun, ça doit aller vite (compilateur JIT) et utiliser correctement la mémoire. On peut configurer finement comment JVM utilise la mémoire.
[^] # Re: Hordes de zombies
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche La République Populaire de Chine impose un logiciel de contrôle d'accès défaillant. Évalué à 1.
Pourquoi est-ce que seuls des chinois exploiteraient les failles ? Pourquoi pas, par exemple, un ennemi de la Chine ? Les opposants au régime par exemple. Un troyan qui installerait Freenet partout (en mode opennet), ça serait un sacré pied de nez au gouvernement ;-)
# Merci !
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Meilleurs contributeurs LinuxFr : Les gagnants de mai 2009. Évalué à 8.
Et bien sûr : proposez vos dépêches si vous voulez vous aussi recevoir des cadeaux ! Ça coûte juste un peu de temps ;-)
# En la compression par ondelette, on en est où ?
Posté par Victor STINNER (site web personnel) . En réponse au journal i2bp est mort , vive I-CES !!. Évalué à 5.
http://www.ece.uvic.ca/~mdadams/jasper/
Dirac, codec vidéo libre utilisant des ondelettes :
http://linuxfr.org/2008/09/21/24510.html
Il existe d'autres projets ?
[^] # Re: Pas de bol
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche La République Populaire de Chine impose un logiciel de contrôle d'accès défaillant. Évalué à 2.
http://fr.wikipedia.org/wiki/La_Saveur_de_la_pastèque
(en fait, je ne l'ai regardé que partiellement, il est trop bizzare ce film :-p)
... bon, c'est un film franco-taïwanais, alors que là on parle de la République Populaire de Chine, c'est pas pareil.
[^] # Re: Echantillon représentatiff?
Posté par Victor STINNER (site web personnel) . En réponse au journal Windowmaker toujours le WM favori. Évalué à 2.
[^] # Re: Et sinon, pour les utilisateurs normaux ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche ext3 est mort ? Vive ext4 !. Évalué à 7.
Les extends sont très bénéfiques en vitesse de lectures de gros fichiers (un avi de 650 Mo ? non, une ISO Debian de 5 Go bien sûr !). Je pense qu'ils sont également bénéfiques en vitesse d'écriture (pour les disques utilisant des têtes de lecture, car ext4 en limite le déplacement).
[^] # Re: Libre
Posté par Victor STINNER (site web personnel) . En réponse au journal Sortie de Freenet 0.7.5RC1. Évalué à 2.
Sinon une ou plusieurs couches de transport stéganographiques sont prévues à terme (version 0.9 si je ne m'abuse).
Euh, oui, un ami (développeur Freenet) m'en parlait déjà y'a 2/3 ans, mais en pratique il n'y a toujours rien d'implémenté.
Enfin quant à trouver si quelqu'un utilise Freenet, c'est tout à fait possible en créant beaucoup de noeuds s'il est connecté à l'opennet
Je pensais plus à du flicage fait par l'État qui peut se permettre de rajouter des sondes chez les FAI. La censeurs (ça existe ce mot ? personne qui censure) sont souvent haut placés et ont des moyens.
Et quand bien même il utilise Freenet, le trafic est lissé de sorte à ne pas laisser déceler une éventuelle insertion
Oui, je disais juste que si on peut sniffer la connexion d'un internaute, on peut savoir s'il utilise Freenet ou pas. Tout ça pour dire que je doute que Freenet aide dans les pays où Internet est fortement censuré et surveillé de près.
Après, bien sûr que Freenet est un chouette projet. Il peut servir à pas mal de choses, et j'espère qu'il sera utilisé pour de bonnes choses (comme la liberté d'expression).
[^] # Re: Libre
Posté par Victor STINNER (site web personnel) . En réponse au journal Sortie de Freenet 0.7.5RC1. Évalué à 6.
D'ailleurs, Freenet vise (entre autres) les chinois qui sont (je pense) majoritairement sous Windows. Un chinois qui utilise Linux, à mon avis il est directement vu comme un mec louche...
D'ailleurs, j'avais regardé un peu Freenet et je trouve qu'il n'a rien de discret :
* Il utilise des ports TCP non conventionnels
* Les paquets sont entièrement chiffrés et ça se remarque facilement (ex: mesurer l'entropie des paquets)
* Fonctionnement P2P : envoie beaucoup de données, alors qu'un internaute qui surfe sur des sites web (en HTTP) émet peu de données
Je veux dire qu'une personne qui peut sniffer une connexion Internet (possible si on a accès aux routeurs des FAI, ce qui est le cas pour un état, tout particulièrement en Chine) n'aura pas de mal à remarquer que l'internaute utilise Freenet. Et vu la faible popularité de Freenet, un mec qui l'utilise est forcément louche...
PS: Je parle de la Chine parce qu'il est connu qu'Internet y est filtré, mais aussi que les opposants au régime n'ont pas intérêt à se faire chopper via Internet. De nombreux autres pays censurent Internet, et c'est parfois bien pire.
http://map.opennet.net/filtering-pol.html
http://linuxfr.org/2009/04/20/25332.html
[^] # Re: Superbe dépêche
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Le noyau Linux 2.6.30 est disponible. Évalué à 7.
Details: The infrastructure is all in place. The driver details are as follows: For AMD/ATI hardware, R300 and newer has KMS enabled by default; R100-R200 does not yet have 3D support with KMS, so is default to disabled (this has been targeted for Fedora 11). For Intel hardware, we default to disabled (targeted for Fedora 11).
http://fedoraproject.org/wiki/Features/KernelModesetting
Le détail :
http://fedoraproject.org/wiki/Features/IntelKMS
http://fedoraproject.org/wiki/Features/NouveauModesetting
http://fedoraproject.org/wiki/Features/Radeon3DUpdate
Par contre, vu que Fedora 11 est sorti avant le noyau 2.6.30, il utilise forcément le noyau 2.6.29.
[^] # Re: Nettoyage de mémoire
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Le noyau Linux 2.6.30 est disponible. Évalué à 9.
Je pense que tu peux faire une attaque coldboot avec la machine en fonctionnement (extraire la barrette de mémoire alors que l'ordinateur tourne toujours). Si ton objectif est de lire le disque dur, tu peux débrancher le disque dur, arracher la mémoire (bon, pas sûr qu'elle soit contente), récupérer la clé (en mémoire) du disque dur, puis brancher le disque dur sur un autre ordinateur sain.
Il existe un projet visant à ne pas stocker les clés privées en mémoire : les clés ne seraient que présentes dans le cache du processeur (cache L1 je pense). Bon, après il doit être possible de lire la mémoire du CPU. Tout dépend des moyens qu'on se donne. Des ingénieurs d'IBM ont bien réussi à écrire dans le cache L1 d'un CPU avec un laser, et des hackers ont réussi à lire des clés de chiffrement Xbox en lisant ce qui passe sur le port PCI (je me souviens plus des détails) :-)
http://frozencache.blogspot.com/
[^] # Re: "véritable sens"
Posté par Victor STINNER (site web personnel) . En réponse au journal Retours sur OxyRadio : réponses et réactions. Évalué à 2.
[^] # Re: je vais me faire charrier mais...
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Le noyau Linux 2.6.30 est disponible. Évalué à 10.
[^] # Re: Merci pour la dépêche et nouvelle amélioration : sommaire
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Le noyau Linux 2.6.30 est disponible. Évalué à 9.
[^] # Re: quel joli nom
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Open Object - Un nouveau site communautaire pour Open ERP. Évalué à 8.
http://www.open.com/
http://www.object.com/
[^] # Re: php ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Open Object - Un nouveau site communautaire pour Open ERP. Évalué à 4.
Bien sûr, l'auteur de l'article a vérifié la véracité des informations avant de poster :-) Bon et puis c'est pas comme si les journalistes modifiaient des fois le texte d'une citation avant de publier un article...
Article intéressant à ce sujet : faut-il accepter de passer à la télévision si la conclusion est écrite d'avance ?
http://sid.rstack.org/blog/index.php/345-les-marches-de-la-g(...)
(c'était au sujet d'un reportage fait à l'arrache sur la sécurité informatique)
# PHP4 déprécié, PHP6 annoncé
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Concours de design FullCSS. Évalué à 5.
http://linuxfr.org/~supergab/24952.html
Août 2008, la dernière mise à jour de PHP 4(.4.9) est publiée :
http://www.php.net/releases/4_4_9.php
Vu la quantité de failles de sécurité qui pleuvent sur PHP, je trouve que ça fait pas très sérieux de continuer à l'utiliser / le proposer : « À gagner : Un hébergement de 2 ans, supportant PHP4, PHP5, MySQL. »
Bon et PHP6 alors, c'est mort ? C'est comme Perl6. Y'a ceux qui parlent (PHP6/Perl6 c'est super, ça tue tout, blablabla), et ceux qui codent (Python3 sorti fin 2008).
[^] # Re: En même temps...
Posté par Victor STINNER (site web personnel) . En réponse au journal Banni de chez Microsoft.. Évalué à 5.
[^] # strlcpy plus rapide que strncpy
Posté par Victor STINNER (site web personnel) . En réponse au journal Banni de chez Microsoft.. Évalué à 3.
« man strncpy : (...) Dans le cas où la longueur de src est inférieure à n, la fin de dest sera remplie avec des caractères nuls. »
[^] # Re: Place d'Hasard par rapport à GSL, OpenSSL & cie
Posté par Victor STINNER (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 2.
Je préfère attendre la prochaine version, voir la version 1.0. À vrai dire, j'aimerai qu'Hasard soit utilisé par une vraie application pour pouvoir peaufiner (et corriger) l'API avant de faire une grosse campagne de buzz :-)
faudrait aussi faire des binding python/perl/php & co ... yaka fokon ;)
Il y a déjà un binding Python. Je ne connais pas assez bien Perl et PHP pour écrire un binding pour ces langages. L'idéal serait qu'Hasard soit utilisé par Python, Perl, PHP & cie pour leur fonction "rand" :-)
[^] # Re: .
Posté par Victor STINNER (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 3.
C'est justement pour éviter que chacun recode sa fonction randrange(a,b), un peu biaisée voir complètement fausse, que j'ai codé Hasard.
La fonction hasard_engine_ulong() a subi de nombreuses réécritures et corrections :
* Hasard 0.1 : utilisation des flottants mais avec un arrondi foireux, les bornes (min/max) étaient 2x moins fréquentes :-/
* Hasard 0.3 : correction pour les bornes
* Hasard 0.4 : support des générateurs dont l'intervalle de sortie est plus petit que celui demandé par l'utilisateur
* Hasard 0.5 : réécriture de l'algorithme, utilise GMP et uniquement des nombres entiers (pour supporter les CPU 64 bits)
* Hasard 0.6 : réécriture de l'algorithme, basé sur celui de GSL, pour se passer de GMP (pour limiter les dépendances)
Je pense que l'algorithme actuel est bon. Il reste juste à gérer un dernier cas : quand ULONG+1 n'est pas un multiple de l'intervalle de sortie du générateur (cas rare, arrive pour certains générateurs peu utilisés et déconseillés).
[^] # Ne pas utiliser modulo
Posté par Victor STINNER (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 2.
J'ai écrit ce document qui présente les erreurs courantes :
http://haypo.hachoir.org/hasard?file/tip/doc/common_errors.r(...)
Disons que l'intervalle de sortie du générateur soit [a; b] et celui que veut l'utilisateur est [x; y]. On peut utiliser le modulo à condition que :
* [a; b] soit plus grand (ou de même taille) que [x; y] : (b-a+1) >= (y-x+1)
* (b-a+1) soit multiple de (y-x+1)
Exemple : générateur : [0; 99] (100 nombres), utilisateur : [0; 9]. Si le générateur est uniforme, rand() % 10 sera aussi uniforme.
--
Hasard réutilise l'idée de l'algorithme de GSL, mais tire plusieurs nombres si l'intervalle du générateur est plus petit que celui de l'utilisateur. L'algorithme général est :
1. tirer un nombre au hasard
2. diviser ce nombre par un facteur (pour limiter le nombre d'itérations)
3. si le nombre est plus grand que ce que veut l'utilisateur, recommencer (retour en 1.)
Voir lib/randint.c pour les détails :
http://haypo.hachoir.org/hasard?file/tip/lib/randint.c
--
Autre document utile : présentations des implémentations de PRNG existantes, avec quelques bugs que j'ai noté :
http://haypo.hachoir.org/hasard?file/tip/doc/real_world.rst
# Place d'Hasard par rapport à GSL, OpenSSL & cie
Posté par Victor STINNER (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 10.
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.
# Annonce reprise par
Posté par Victor STINNER (site web personnel) . En réponse au journal Debian migre de la GNU libc à EGLIBC. Évalué à 1.
http://lwn.net/Articles/332000/