Victor STINNER a écrit 1639 commentaires

  • # L'OS à moëlle

    Posté par  (site web personnel) . En réponse au journal Test Mandriva par ZDNet : waouh !. Évalué à 9.

    Exemple : les mises à jour auto ont un spectre bien plus large que sous Win, parce que la gestion des packages ne recouvrent pas que l'OS.

    Ils recouvrent aussi les muscles ?
  • [^] # Re: Ah ah ! Trop gros ça ne passera pas !

    Posté par  (site web personnel) . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 6.

    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.
  • [^] # Re: Hordes de zombies

    Posté par  (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.

    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 ;-)
  • # Merci !

    Posté par  (site web personnel) . En réponse à la dépêche Meilleurs contributeurs LinuxFr : Les gagnants de mai 2009. Évalué à 8.

    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 ;-)
  • # En la compression par ondelette, on en est où ?

    Posté par  (site web personnel) . En réponse au journal i2bp est mort , vive I-CES !!. Évalué à 5.

    Implémentation libre de JPEG2000 :
    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  (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.

    En même temps, il existe des films pornographiques chinois. J'en ai au moins vu un :
    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  (site web personnel) . En réponse au journal Windowmaker toujours le WM favori. Évalué à 2.

    Avez vous regardé de quand date le sondage ?
  • [^] # Re: Et sinon, pour les utilisateurs normaux ?

    Posté par  (site web personnel) . En réponse à la dépêche ext3 est mort ? Vive ext4 !. Évalué à 7.

    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).
  • [^] # Re: Libre

    Posté par  (site web personnel) . En réponse au journal Sortie de Freenet 0.7.5RC1. Évalué à 2.

    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).
  • [^] # Re: Libre

    Posté par  (site web personnel) . En réponse au journal Sortie de Freenet 0.7.5RC1. Évalué à 6.

    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...

    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  (site web personnel) . En réponse à la dépêche Le noyau Linux 2.6.30 est disponible. Évalué à 7.

    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

    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  (site web personnel) . En réponse à la dépêche Le noyau Linux 2.6.30 est disponible. Évalué à 9.

    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/
  • [^] # Re: "véritable sens"

    Posté par  (site web personnel) . En réponse au journal Retours sur OxyRadio : réponses et réactions. Évalué à 2.

    Le véritable sens est une ville en Yonne.
  • [^] # Re: je vais me faire charrier mais...

    Posté par  (site web personnel) . En réponse à la dépêche Le noyau Linux 2.6.30 est disponible. Évalué à 10.

    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 :-)
  • [^] # Re: Merci pour la dépêche et nouvelle amélioration : sommaire

    Posté par  (site web personnel) . En réponse à la dépêche Le noyau Linux 2.6.30 est disponible. Évalué à 9.

    C'est du HTML tout bête (HTML 1.0 ?) : une ancre (a name="nom de l'ancre") puis une référence à l'ancre (a href="#nom de l'ancre").
  • [^] # Re: quel joli nom

    Posté par  (site web personnel) . En réponse à la dépêche Open Object - Un nouveau site communautaire pour Open ERP. Évalué à 8.

    Les noms Open et Object étaient déjà pris :-)
    http://www.open.com/
    http://www.object.com/
  • [^] # Re: php ?

    Posté par  (site web personnel) . En réponse à la dépêche Open Object - Un nouveau site communautaire pour Open ERP. Évalué à 4.

    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)
  • # PHP4 déprécié, PHP6 annoncé

    Posté par  (site web personnel) . En réponse à la dépêche Concours de design FullCSS. Évalué à 5.

    Juillet 2007, la fin de PHP4 et la début de PHP6 est annoncée :
    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  (site web personnel) . En réponse au journal Banni de chez Microsoft.. Évalué à 5.

    Je trouve ça nul de refuser strlcpy()/strlcat() mais conserver gets() qui est connu pour être complètement troué de par sa conception !
  • [^] # strlcpy plus rapide que strncpy

    Posté par  (site web personnel) . En réponse au journal Banni de chez Microsoft.. Évalué à 3.

    Il me semble que strlcpy() est plus rapide que strncpy() car strlcpy() écrit un seul octet nul, alors que strncpy() remplit de zéro jusqu'à la fin.

    « 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  (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 2.

    t'avais qu'a faire une dépeche :p

    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  (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 3.

    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).
  • [^] # Ne pas utiliser modulo

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

    Est-ce que tu as plus d'explications ou un lien quelconque ?

    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  (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.
  • # Annonce reprise par

    Posté par  (site web personnel) . En réponse au journal Debian migre de la GNU libc à EGLIBC. Évalué à 1.