Le bien connu réseau Freenet, anonyme, chiffré et résistant à la censure, vient de sortir en version de test, 0.7.5 RC1.

Freenet est un réseau anonyme et décentralisé qui date du tout début des années 2000. Conçu pour être avant tout anonyme et résistant à la censure, il se présente comme une surcouche à internet, avec ses sites, ses blogs, ses forums, son partage de fichier et ses emails.
Chaque participant fournit une partie de son disque dur et de sa bande passante au pool de ressources global du réseau, et participe ainsi à son expansion. Les participants ont le choix de s'y connecter via deux méthodes : l'opennet, où il se connecte à des inconnus, et le darknet, où il ne se connecte qu'à des amis (IRL) de confiance.

Cette version apporte les améliorations suivantes :
* utilisation d'une base de donnée pour le datastore. Ceci ainsi que diverses améliorations réduit considérablement l'utilisation CPU par rapport aux anciennes versions (d'un facteur 3 à 5).
* amélioration de l'interface web
* grosses amélioration de la vitesse d'insertion et téléchargement, de la navigation sur les freesites et de la prise en compte des nouveaux nœuds sur le réseau
* etc. etc.

Les principaux axes de développement concernent un nouveau système de forum, basé sur un "web of trust" et l'amélioration de l'anonymat par ajout de routage aléatoire des requête avant leur diffusion sur le réseau.

Pour installer, c'est par ici :
http://checksums.freenetproject.org/latest/freenet.jnlp

Le site web du projet :
http://freenetproject.org/

Un bon résumé sur les forums de numerama, sur le thème comment faire pour que ce soit le plus rapide possible (chercher la chaîne "je résume"), et les compromis taille de store/débit alloué/uptime du PC sur lequel il y a le nœud :
http://www.numerama.com/forum/index.php?showtopic=95338

> Lire le journal (27 commentaires, moyenne: 4,4).

Bonjour à tous,

Heureux possesseur d'un Fit-PC slim (www.fit-pc.com) tout neuf, je vous fais part de quelques tests et ordres de grandeur sur la puissance de calcul de la bête.

Matériel : AMD Geode LX 800 (500MHz), disque dur IDE 5400 tpm. Processeur x586 (686 est possible mais émulé, donc non recommandé), chiffrement AES-128 et générateur aléatoire matériel.
Distribution : Debian lenny (etch initialement, passée en lenny vu l'imminence de sa parution). Je passe sur l'installation à partir d'une clef USB via une console série, tout se passe bien quand on se décide à prendre l'image toute faite (qui nécessite une clef de 256MB) au lieu de tenter d'utiliser une clef 128 en copiant a minima les fichiers (image ISO businesscard), je vous laisse consulter http://www.debian.org/releases/stable/i386/ch04s04.html.fr ). Ne pas oublier de préciser la console dans syslinux.cfg.


1) Modules matériels crypto & random.
Le module de chiffrement AES et le générateur aléatoire matériel sont bien reconnus sous Linux depuis les versions 2.6.2x. Il est donc naturel d'essayer de quantifier leur apport dans le cadre d'une utilisation pratique.

1.1) AES
L'application première d'un tel module sous Debian est bien évidemment le chiffrement des partitions (LVM pour /, /boot excepté). Bien sélectionner chiffrement AES-128-CBC à l'installation, le mode CBC étant (avec le mode ECB qui n'est pas recommandé) le seul supporté par le module matériel. On ajoute un ESSIV sha256 pour plus de sécurité (ça aura un impact comme vous le verrez). On évite par contre le remplissage du disque avec de l'aléas vu la puissance du processeur (le module matériel n'étant pas utilisable faute de module compilé dans l'image d'installation), à faire ensuite.
On ajoute geode-aes au fichier /etc/initramfs-tools/modules pour qu'il soit chargé et utilisable par l'API crypto du noyau dès le démarrage.

Exemple de résultat significatif (refaits plusieurs fois, aucun service ne tournant à part sshd):

hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 90,6 MB in 3.05 seconds = 29,7 MB/sec



hdparm -t /dev/mapper/ma_partition_chiffrée
/dev/hda:
Timing buffered disk reads: 41,6 MB in 3.05 seconds = 13,7 MB/sec

ce qui est très correct. À noter que sha256 en logiciel fait tourner le processeur à plein, c'est donc lui qui nous limite. Ce ne serait sans doutes pas le cas avec un module matériel crypto un peu plus développé (par exemple via padlock).

Si on retire le module geode-aes de l'initrd, les performances chutent drastiquement:

hdparm -t /dev/mapper/ma_partition_chiffrée
/dev/hda:
Timing buffered disk reads: 17.4 MB in 3.05 seconds = 5,7 MB/sec

ce qui n'est pas vivable.

1.2) Module d'aléas
on charge le module geode-rng par la commande modprobe geode-rng , il faut installer le paquet rng-tools pour qu'il soit utilisé. Ce paquet installe le démon rngd, qui est chargé de récupérer l'aléas du générateur matériel 20000 octets par 20000 octets, d'effectuer des tests cryptographiques (FIPS) dessus pour en vérifier la qualité, et ensuite de l'ajouter au pool d'entropie du noyau. On peut ensuite lire /dev/random (oui ami lecteur, tu as bien vu ! random et non urandom ou autres !) à plus ou moins 70ko/s (vérifier avec la commande dd if=/dev/random of=/dev/null ). Le démon rngd occupe environ 30% du processeur, le reste pour dd.

2) Le processeur en lui-même
Je voulais profiter d'une des innovations de la dernière version de gcc, à savoir l'apparition d'une option de compilation spécifiquement dédiée au geode LX.

2.1) Le noyau
Les sources du noyau Linux ne prennent pas encore en compte cette possibilité, il faut modifier (légèrement) un des Makefile pour que l'architecture soit la bonne
# Geode LX support
cflags-$(CONFIG_MGEODE_LX) += -march=geode
au fichier arch/x86/Makefile_32.cpu donnent l'option demandée (vérifiable avec ps aux |grep geode durant la compilation du noyau par exemple).
3 heures de compilation avec make-kpkg plus tard (noyau allégé de beaucoup de modules et de pilotes inutiles... je peux fournir mon .config si quelqu'un est intéressé), reboot, pas d'amélioration significative propre à l'architecture à mesurer (j'ai également modifié d'autres paramètres, la préemption et la fréquence de base) sauf peut-être un temps de démarrage plus rapide au niveau de l'initrd et de la détection du matériel, et une légère amélioration de la vitesse de lecture sur disque (de l'ordre de 3 à 4 % peut-être ? mais les mesures fluctuant déjà pas mal, je n'ai pas fait de stats détaillées. L'ordre de grandeur reste le même de toutes façons :-)

2.2) Benchmark nbench (http://www.tux.org/~mayer/linux/ ) avec différentes options de compilation.
Les différentes sources sur internet précisent qu'en général, vu le faible cache du geode LX (64kB = 32kB instructions, 32 kB données pour le L1, 128 kB pour le L2) il vaut mieux compiler avec l'option -Os (réduit la taille du code) plutôt que -O3) je voulais voir un peu ce qu'il en était et jouer avec les différentes options d'optimisation de gcc. Notamment, prendre un -Os mais en ajoutant certaines optimisation (précisées comme pouvant avoir un impact au niveau

Il devient possible de mesurer l'impact du choix de l'architecture face à un x86 générique, on obtient des gains de temps allant de 20 à 50% suivant les options !!
À noter que comparé à la liste des processeurs présentés ici http://www.tux.org/~mayer/linux/results2.html , le geode se sort très honorablement des tests faisant appel à la mémoire et au calcul sur les entiers, par contre est très lent en ce qui concerne les flottants - peu étonnant, la fiche technique détaillée disponible à http://www.amd.com/files/connectivitysolutions/geode/geode_l(...) précise en effet page 202 que les opérations sur les double sont émulées et prennent beaucoup plus de temps que les opérations sur des float).

Les résultats sont les suivants, idem je peux fournir les résultats détaillés (différents tests sont exécutés, par exemple transformée de Fourier, chiffrement IDEA, tri, etc. les résultats varient suivant les options) :

kernel : 2.6.26-geode
C compiler : gcc version 4.3.2 (Debian 4.3.2-1)
libc : libc-2.7.so

NATIVE
-s -static -Wall -O3
MEMORY INDEX : 11.665
INTEGER INDEX : 12.023
FLOATING-POINT INDEX: 10.855

GEODE (arch, O3 plus some optimizations)
-s -static -O3 -fomit-frame-pointer -Wall -march=geode -fforce-addr -falign-loop
s=2 -falign-functions=2 -falign-jumps=2 -funroll-loops
MEMORY INDEX : 15.813
INTEGER INDEX : 13.508
FLOATING-POINT INDEX: 10.766

OPTIMIZE FOR SIZE (same options, except O3 is replaced by Os)
-s -static -fomit-frame-pointer -Wall -march=geode -fforce-addr -falign-loops=2 -falign-functions=2 -falign-jumps=2 -funroll-loops -Os
MEMORY INDEX : 15.680
INTEGER INDEX : 13.271
FLOATING-POINT INDEX: 10.642

OPTIMIZE FOR SIZE, PLUS SOME O3 & OTHER OPTIMIZATIONS:
-s -static -fomit-frame-pointer -Wall -march=geode -fforce-addr -falign-loops=2 -falign-functions=2 -falign-jumps=2 -funroll-loops -fsee -ftree-vectorize -ffast-math -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload -Os
MEMORY INDEX : 16.333
INTEGER INDEX : 13.335
FLOATING-POINT INDEX: 10.774


3) Compléments
Les impressions générales sont bonnes, le processeur n'est pas très rapide mais il fonctionne très bien et il y a de la place pour bons nombres de services sur une telle configuration. J'avais vraiment peur pour des applications java, mais il s'en sort très bien. À ce sujet, il vaut mieux les lancer avec l'option java -server :-) pour un gain de performances sensible même si là encore non quantifié avec précision vu les variations de charge de l'application.

Les capteurs de température fonctionnent très bien, pour fixer un ordre de grandeur à pleine charge le processeur monte à 47°C (pour une température recommandée inférieure à 70°C, critique à 85°C, le CPU chauffe un peu plus (70°C, max recommandé 86°C, critique 126°C). Pendant ce temps, le disque beaucoup sollicité monte à 43°C (c'est un seagate momentus). Le boîtier chauffe pas mal, mais on peut en général laisser la main dessus, d'ailleurs c'est amusant ce faisant on voit tout de suite la température baisser ! ben oui, la main au contact du boîtier évacue mieux la chaleur que l'air ambiant sans ventilation ni radiateur !). Enfin, la machine est aussi silencieuse que le disque dur, c'est-à-dire qu'on n'entend quasiment rien.

À suivre : recompilation d'autres packages laissant espérer des gains appréciables quant aux optimisations liées à l'architecture (comme la libc...), apt-build semble être mon ami. Le flag -O3 (ou d'autres flags d'optimisation de la compilation) sont-ils réellement vecteurs d'instabilité ? http://gentoo-wiki.com/CFLAGS_matrix dit qu'il est considéré risqué, mais sans plus... Des retours d'expérience sur apt-build et -O3 ?

Le plus impressionnant est selon moi les perfs du module matériel AES, openssl dispose d'un engine lui permettant d'utiliser le padlock de via, à quand un patch pour le geode ? Sinon il y a un projet qui cherche à proposer l'API crypto du noyau comme engine openssl (ocf framework for linux, http://ocf-linux.sourceforge.net/ mais je n'ai pas vu grand-chose d'utilisable pour le moment. Dommage, si j'avais le temps et les compétences j'essaierais de contribuer, car certains trucs seraient très intéressant : utiliser ssh en précisant le mode de chiffrement AES-128-CBC, et éviter une grosse montée en charge, bien visible avec top, lors de transferts de fichiers un peu gros à haut débit (même sans compression. Avec ssh -C, c'est pire !)).

PS (je profite de ce journal pour poser une question qui aurait plutôt sa place dans les forums, pardonnez-moi svp :) : si quelqu'un a acheté le même PC, peut-il me dire si le wi-fi est désactivé par défaut dans le BIOS ou non ? impossible de le faire fonctionner (j'ai tout essayé, chargé les modules rt73usb & co, installé les firmware du site de ralink dans /lib/firmware, rien n'y fait pas de nouvelle interface réseau !), et je n'ai pas d'écran facilement accessible pour vérifier (d'où l'installation par une console série).

> Lire le journal (17 commentaires, moyenne: 3,6).

http://www.lefigaro.fr/international/2008/03/20/01003-200803(...)

On pourra noter les points suivants :
1) Obligation pour les fournisseurs d'accès à Internet de laisser le FSB (ex-KGB) à contrôler sites et mails qui passent par leur biais
2) (suite du 1) ) et donc à s'équiper de technologies permettant le contrôle, à leurs frais.
3) interdiction du rachat des FAI russes par des entreprises étrangères
4) Création d'une agence pour superviser Internet.
5) qui pourrait faire assimiler les blogs à des médias d'information (statut plus facilement soumis à pression)

La Russie comporte environ 35 Millions d'internautes. Internet a été un vecteur important de la mobilisation politique en Ukraine, et est actuellement le refuge principal de l'opposition politique en Russie.

> Lire le journal (32 commentaires, moyenne: 3,8).

cf http://www.selmarrant.com/spip/IMG/pdf/Analyse_de_l_enquete_(...)
qui contient l'analyse d'une enquête menée sur les logiciels libres par la société Cyberlog (http://cyberlog-corp.com/cyberlog/ )sur 180 personnes, entre ?? et ??)

Il en ressort notamment que si fiabilité et performance sont la partie la plus importante des critères de choix lors de l'équipement en logiciel, le choix d'utilisation des logiciels libre est avant tout question de gratuité et de refus de monopole, ainsi que de transparence.

Les deux premiers logiciels libres spontanément cités sont Linux puis Firefox, avec OpenOffice.org un peu plus loin derrière.

Commentaires : on aurait aimé, outre les dates entre lesquelles l'enquête a été réalisée, en savoir un peu plus sur les personnes interrogées, les enquêtes menées sur internet (cf http://cyberlog-corp.com/cyberlog/formulaire.php?act=liste_e(...) ) étant connues pour leur difficulté à justifier le choix de l'échantillon (ni méthode des quotas ni échantillon choisi totalement au hasard, flood possible etc. ).

Par ailleurs, vu que l'enquêteur a appelé diverses entreprises pour avoir une idée de leur taux de connaissance des logiciels libres, on aurait aimé avoir une idée de ce taux afin de pouvoir mettre cette enquête en perspective.

> Lire le journal (3 commentaires, moyenne: 4,3).

Selon PCInpact, une entreprise (Educafix pour ne pas la nommer) envisageait de développer son logiciel (Educaxion), basé sur un autre Baghera.

baghera avait été developpé par une université de Grenoble, avec un contrat avec Educafix.

Baghera se basant sur un composant sous GPL (JATLite), développé par l'université de Stanford, suite à un litige au sujet du contrat la justice française a estimé que les deux parties auraient dû demander une licence spéciale à Stanford :

C'est peut-être une victoire en demi-teinte, le tribunal ayant estimé que "Ce programme a la particularité de dépendre de la licence GNU qui permet une utilisation libre du logiciel mais requiert une licence si le travail basé sur le programme ne peut être identifié comme raisonnablement indépendant et doit être considéré comme dérivé du programme initial"

En effet, la GPL ne requiert pas une licence spécifique pour faire du logiciel propriétaire à base de GPL, mais requiert que le programme dérivé soit sous GPL ou une licence compatible.

cf http://www.pcinpact.com/actu/news/37313-GPL-GNU-licence-libr(...)

> Lire le journal (14 commentaires, moyenne: 3).