Je viens de construire le diff entre Bind 9.4.2 et Bind 9.4.2-P1 pour voir à quoi ça ressemble. J'ai ignoré une partie de la doc qui gonflait astronomiquement le patch :

http://ngc891.blogdns.net/pub/projects/patches/bind-9.4.2.pa(...)
http://ngc891.blogdns.net/pub/projects/patches/bind-9.4.2.pa(...) (version en couleurs)

Ce n'est, de toute évidence, pas un patch trivial. On dira également merci au ARC4 d'OpenBSD.

[ Répondre ]

Si vous voulez tester rapidement OpenBSD sans vous embêter à partitionner votre disque, voici quelques explications pour le faire avec KVM :

1) Installer kvm sur votre distribution si ce n'est pas déjà fait (et vérifiez que vous avez bien le pilote kvm dans le kernel : $ zcat /proc/config.gz | grep KVM ) :
http://kvm.qumranet.com/kvmwiki

2) Créer un fichier pour l'image disque (2Go est un minimum, il vaudrait mieux mettre 5Go ou 10Go si vous avez la place pour tester les packages/ports) :
$ qemu-img create OBSD 5G

3) Téléchargez l'ISO de développement (remplacer i386 par amd64 ou macppc, etc) :
$ wget ftp://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/i386/install4(...)

4) Booter l'ISO en utilisant l'image disque :
$ qemu -hda OBSD -cdrom install44.iso -boot d -net nic,model=ne2k_pci -net user

- qemu s'appelle peut-être qemu-system-$ARCH sur votre système
- les options -net permettent de changer la carte réseau émulée par qemu car celle par défaut plantouille sous OpenBSD.

5) Suivre les instructions données ici :
http://openbsd.org/faq/fr/faq4.html#Install

- utilisez tout le disque
- paramétrez le réseau en dhcp
- média d'installation : cd
- après avoir lancé la commande halt, fermez qemu.

6) Après installation, démarrez le système via :
$ qemu OBSD -net nic,model=ne2k_pci -net user

Lire la page de man de qemu, de nombreuses choses sont paramétrables.

[ Répondre ]

Tu bluffes Martoni !

[ Répondre ]

urandom est non bloquant mais il est lent et utilise (et réutilise) l'entropie du système. Ça peut être ennuyeux de se retrouver à court d'entropie pour d'autres applications.

L'auteur du patch écrit :
It seems the random number generator of libcrypto++ reads lots of bytes from /dev/urandom. I can't say that I understand how the donkey protocol works, but I doubt that's there any need for real strong encryption, and so rand() should do fine for random numbers.

En fait, urandom n'est même pas fait pour le chiffrement fort (voir la page de man). L'efficacité de /dev/random (en quantité) et /dev/urandom (en qualité) est toute relative. Le projet HLFS (Hardened Linux From Scratch) utilise d'ailleurs frandom et erandom :
http://billauer.co.il/frandom.html

Est-ce que le changement baisse la sécurité ?
X917RNG est de bonne qualité couplé avec du Triple DES. Malheureusement, le problème provient toujours de l'initialisation de l'algorithme. Si on n'utilise pas de source entropique, il peut être possible de prévoir la valeur du seed et donc de casser tout le système.

C'est ce qui s'est passé avec Netscape que David Wagner a cassé en 1995 :
http://www.cs.berkeley.edu/~daw/my-posts/netscape-cracked-0

Ici, il semble que AutoSeededX917RNG construit un seed à partir de rand(), qui n'est pas vraiment imprévisible...

Bref, l'entropie, c'est bon, mais je crois que décidément, ça ne plait pas aux debianistes.

[ Répondre ]

Dans le ChangeLog, on appréciera le :
Patch for debian bug #350396: "amule depletes entropy pool".

À noter qu'aMule dépend maintenant de la bibliothèque crypto++.

[ Répondre ]

Qui te parle de Nautilus ?

Moi je n'ai pas Nautilus d'installé sur mon système et lister tous les fichiers de /usr/bin avec le sélecteur de fichier GTK met effectivement 3 plombes.

Preuve que ta démonstration n'en est pas une.

[ Répondre ]

Maintenant, ça tourne bien.

On vient tout juste de passer la barre des 2,5 millions de téléchargements. Impressionnant.

[ Répondre ]

l'inconstance des API et ABI n'est pas un problème dans le monde du libre

Je crois que tu sous-estimes légèrement la difficulté de la tache. Il y a de plus en plus de projets libres qui n'arrivent plus à suivre le rythme de développement du noyau.

Juste un exemple : le projet grsecurity, qui essaie de renforcer la sécurité du noyau, vient de jeter l'éponge : trop de travail. Ils vont se rabattre sur le noyau LTS d'Ubuntu. Tant pis pour les autres. http://grsecurity.net/pipermail/grsecurity/2008-May/000927.h(...)

Ce n'est pas un problème libre/propriétaire, car au final, NVIDIA sort bien un nouveau driver régulièrement ; mais force est de constater, que sans l'appui financier d'une entreprise, il deviendra de plus en plus difficile de contribuer sérieusement au noyau. Je ne parle pas de coder des nouvelles choses, mais bien de maintenir son code.

Le diff entre Linux 2.6.20 et 2.6.25 fait 143Mo (19 319 patches), ce qui fait une moyenne (je ne l'ai pas inventé :-) de 42 patches par jour, ça donne de quoi s'occuper...

[ Répondre ]

Ce pilote en beta ne supporte que les noyaux <=2.6.25 mais pas le 2.6.26 qui est actuellement en développement.

C'est l'intérêt de la version patchée que je propose dans le journal.

[ Répondre ]

Je crois qu'ici c'est plus les dev noyaux qui sont responsables en pétant régulièrement l'API

Ça devient une tradition de casser des choses à chaque nouvelle sortie de 2.6.X. Je n'ai rien contre les changements d'API, mais ça devrait, autant que possible, se faire dans une branche de développement et pas dans une branche stable. Parce que là, c'est "marche ou crève".

En passant ... t'as envoyé ton patch à nvidia ?

Non. D'une part parce que ce que j'ai fait est trivial, ne s'applique qu'au 2.6.26-rc et n'a surtout pas la prétention de remplacer le pilote officiel.
C'est juste un hack pour ceux qui ne veulent pas attendre 2 ou 3 mois.

[ Répondre ]

D'un autre côté, si on ne peut pas le compiler, on est plutôt bien protégé des bugs :-)

Le problème de la -rc1 c'est qu'elle est le produit d'une somme astronomique de patchs agglutinés en deux semaines. Il y a donc souvent des régressions, mais de là à avoir un noyau qui ne boote pas, ou même un "kernel panic"...

Si tu lis la LKML, tu as du voir le troll fil de discussion initié par David Miller qui proteste parce que les changements vont trop vite et qu'il n'a plus le temps de tester. La position de Linus est plutôt inquiétante car il pense que le système actuel est satisfaisant sous prétexte que c'est le seul moyen d'effectuer suffisamment vite toutes les fusions de code. Mais est-il vraiment obligé d'accepter TOUT ce qu'on lui donne ? A-t-il peur de voir son noyau forké dans le cas contraire ?

Quand on voit la quantité de code qui entre dans Linux, la fréquence des régressions, bugs, code qui ne compile pas, pour une branche dite stable, on est vraiment en droit de se demander où en est la démarche qualité. Et si Linus se satisfait du résultat, car au final la large base d'utilisateurs permet de remonter et corriger la plupart des bugs, on peut aussi se poser la question des trous de sécurité qui sont beaucoup plus difficiles à détecter.

Seul espoir, que la branche -mm, qui va migrer vers linux-next, permette enfin d'avoir un vrai test des patchs. Andrew Morton a, sur ce point, une vraie volonté d'améliorer la qualité du noyau.

[ Répondre ]

Ou une mauvaise volonté.

J'ai déjà signalé à plusieurs reprises la disponibilité de binaires pour Slackware sur la mailing-list. J'ai demandé à ce que soit rajouté une ligne avec le nom et l'adresse du projet dans le wiki. Je n'ai jamais eu de réponse. Je l'ai fait sur la mailing-list mais j'ai aussi contacté directement (au moins 2 fois) les responsables du site web.

Rien.

Alors, bon, moi je n'attends plus grand chose de www.enlightenment.org, SlackE17 va sur ses 3 ans, a été téléchargé plus de 26 000 fois (1,5To) et les slackeux savent bien trouver tout seul les packages. La publicité n'est plus nécessaire.

C'est néanmoins frustrant, à chaque fois que l'on parle de E17 et des binaires disponibles, de voir que SlackE17 est toujours ignoré alors que l'on parle d'autres distributions moins connues comme ArchLinux. Il faut croire que les développeurs d'E17 n'aiment pas Slackware, c'est pas possible autrement.

[ Répondre ]

Et Enlightenment DR17 \o/

Je suis tout juste en train d'envoyer la dernière version de SlackE17 sur les serveur de SourceForge. Ça faisait presque un an que c'était en maturation, il faut dire qu'il y a plus de 60 packages dans la version 20080504.

À voir sur :
http://slacke17.sourceforge.net/

Liste des packages :
http://slacke17.sourceforge.net/packages.html

Téléchargement :
http://sourceforge.net/project/showfiles.php?group_id=148645(...)

[ Répondre ]

Le captcha le plus efficace que je connaisse est celui-la :
http://hotcaptcha.com/

Il faut trouver quelles sont les 3 photos sexy sur un panel de 9 (il y a une version masculine aussi pour adonai<).

[ Répondre ]

Sauf que les insultes viennent toujours du coté d'OpenBSD. Si tu va voir la flamewar de décembre c'était symptomatique : Stallman qui faisait des mails courtois et Theo qui éructait des injures.

Alors que dans ton journal, tu écris :

les responsables de la nouvelle chanson [...] sont des gros cons.
cela aboutit à cette merde
le dessin qui accompagne la chanson est encore plus con
l'excellent projet OpenBSD est parasité par une poignée de connards

Et en même temps, tu critiques :
ces gens (qui) balancent leur venin sur d'autres membres de la communauté

Je ne sais pas trop ou tu veux en venir avec ce journal, mais je peux t'assurer que tu n'en sors pas grandi.

[ Répondre ]

Pour ceux qui s'y intéressent, il y a le projet slacke17 pour avoir un enlightenment E17, mais ça a pas l'air de trop bouger...
http://slacke17.sourceforge.net/

Il y aura une mise à jour pour la sortie de Slackware 12.1 et très probablement, nouveauté, des binaires pour Slamd64, le port x86_64 de Slackware.

[ Répondre ]

J'en sais rien, mais j'ai été surpris par le nom du développeur qui est placé exactement en plein milieu...

[ Répondre ]

Pourquoi pointer sur ce résumé du site linux-foundation alors que les sources de l'auteur de l'étude sont bien plus complètes ? ;-)

http://www.kernel.org/pub/linux/kernel/people/gregkh/kernel_(...)

[ Répondre ]

...je ne suis pas sur que ça règle les problèmes de freeze.

[ Répondre ]

Anyone who expects a source of power from the transformation of the atom is talking moonshine.
-- Ernest Rutherford

[ Répondre ]