Victor STINNER a écrit 1632 commentaires

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

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

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.

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/

Le véritable sens est une ville en Yonne.

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 :-)

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

Les noms Open et Object étaient déjà pris :-)
http://www.open.com/
http://www.object.com/

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)

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

Je trouve ça nul de refuser strlcpy()/strlcat() mais conserver gets() qui est connu pour être complètement troué de par sa conception !

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

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" :-)

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

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

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

http://www.h-online.com/open/Debian-changes-from-GLIBC-to-EG(...)
http://lwn.net/Articles/332000/

Est-ce qu'il serait envisageable qui si un nombre suffisant de distributions (Linux et autres OS) et des développeurs migrent à EGLIBC, la version « officielle » de la libc « FSF » deviennent finalement EGLIBC ? (et que la GNU libc actuelle soit simplement abandonnée)

U.D. est difficile, mais les derniers choix qu'il a fait (...) et ses compétences (...) compensent largement (...)

Tiens, je me souviens du bras de fer dans Linux 2.6 pour un nouvel ordonnanceur de processus : il y avait deux concurrents, donc l'un était meilleur techniquement, mais l'autre acceptait les critiques et n'hésitait pas à expliquer ses choix. Bah c'est le second qui a gagné ;-) La technique n'est pas un argument suffisant.

Je pense que le nom du fichier est bien moins utile que les méta-données d'un fichier. Exemple : pour trouver une photo, mieux vaut rechercher via la date stockée dans le fichier que via le nom du fichier => voir F-Spot. Idem pour trouver la musique : on recherche selon les méta-données (nom de l'artiste, titre de l'album, ...) => voir Amarok.

Récemment j'ai entendu parlé de Gnome Zeitgeist (http://live.gnome.org/GnomeZeitgeist) qui généralise le concept (il doit exister d'autres logiciels dans ce genre).

Et puis, n'oublions pas les Beagle & autres outil de recherche par mot clé (dans le contenu du fichier / les méta-donnéees).

Les métadonnées peuvent être stockées dans le fichier ou en dehors : attributs dans le système de fichier (Mac OS utilise beaucoup ça) ou autre part (base de données à part).

Il semble qu'EGLIBC soit régulièrement synchronisé (mergé) avec la libc « FSF » (la GNU libc). Je vois aussi que le dépôt SVN d'EGLIBC a été crée le 16 août 2006.

Je pense que c'est une bonne chose que la GNU libc migre à git. Ça va faciliter la maintenance des patchs non inclus upstream (git rebase). Par contre, je doute fortement que ça change quoi ce soit au niveau de l'acception des contributions.

Petit rappel des faits (ce que j'ai compris de l'affaire) : à force d'auditer du code source C, Todd C. Miller et Theo de Raadt ont eu l'idée d'écrire des fonctions strlcpy() et strlcat() pour remplacer strcpy(), strncpy(), strcat() et strncat() (quand c'est opportun). strlcpy() et strlcat() ont divers avantages (ex: strlcpy garantit que la chaîne est terminée par un octet nul contrairement à strcat, strlcpy est plus rapide car ne remplit pas la fin par des zéros : en écrit un seul) et défauts (ex: strlcat calcule la taille de la source même si elle a été tronquée et est donc plus lent). En dehors du débat qualités/défauts, c'est surtout un bras de fer entre OpenBSD et les développeurs de la GNU libc : fierté, jalousie, ou que sais je.

De mon point de vue, strlcpy() est bien meilleur que strncpy() et plus sûr (limite les erreurs de programmation). Je ne trouve pas les arguments en défaveur de strlcpy() et strlcat() recevables, et je trouve ça dommage que finalement le choix soit « politique ».

Oui, on peut espérer que les développeurs d'EGLIBC soient plus « ouverts ». Il y a déjà eu des patchs acceptés dans EGLIBC qui risquent de ne jamais être accepté dans la GNU libc (ex: supporter un autre shell que bash). Ça rappelle effectivement les scissions Xfree86/X.org ou Sodipodi/Inkscape qui visaient elles aussi à se passer de développeurs peu coopératifs (cf. plutôt l'inverse de coopératif).

Extrait du changelog complet : « [amd64, i386] The FreeBSD virtual memory subsystem now supports fully transparent use of superpages for application memory; application memory pages are dynamically promoted to or demoted from superpages without any modification to application code. This change offers the benefit of large page sizes such as improved virtual memory efficiency and reduced TLB (translation lookaside buffer) misses without downsides like application changes and virtual memory inflexibility. This is disabled by default and can be enabled by setting a loader tunable vm.pmap.pg_ps_enabled to 1. »

En d'autres termes : FreeBSD 7.2 permet d'utiliser de manière transparentes les superpages (pages mémoire de 4 Mo au lieu de 4 Ko) sans modifier les applications. Pour 100 Mo, une application utilisera 25 superpages au lieu de 25600 pages classiques (4 Ko), ce qui va optimiser l'utilisation de la translation d'adresse (TLB : mémoire virtuelle => mémoire physique) et donc accélérer vos applications.

Il existe un projet similaire pour le noyau Linux :
http://linux-mm.org/HugePages
(ce site regroupe toutes les informations sur la gestion de la mémoire sous Linux)

La pédophilie et le terrorisme sont les arguments en vogue pour les lois liberticides.

En Finlande (fin 2007), c'est la pédophilie qui a été choisie pour commencer à censurer le web. Résultat ? C'est un peu tout et n'importe quoi qui est censuré, en commençant par les sites pornographiques sans oublier les gros vilains sites homosexuels. Après on trouve des trucs rigolos comme des usines de violons, un forum d'entraide Windows (là c'était justifié par contre), etc.

Cette histoire de censure en Finlande a été largement médiatisé grâce au site lapsiporno.info qui a automatisé la détection de sites censurés et en a dressé une liste. Bien sûr, ce site a aussi été censuré...

Pour en savoir plus :
http://en.wikipedia.org/wiki/Lapsiporno.info