Sytoka Modon a écrit 4544 commentaires

> ne prenez surtout pas les propos de zenitram pour la véritée

Tout a fait d'accord. Toutes les grosses distrib modifient le code des applications, donc dès qu'il y a modif, il y a risque. Il n'y a que ceux qui ne font rien qui ne casse rien.

On a déjà parlé de ce bogue ici, on va pas refaire encore une fois de l'anti-debian primaire... Je rappelle juste que Red-Hat et Novell se sont bien abstenus de tout commentaire négatif à l'époque.

Mon propos avait juste pour objectif d'aider Victor dans sa recherche du hasard.

> des personnes connaissant (très) bien les générateurs de nombres aléatoires... ce qui
> est très rare.

C'est une problématique bien connu dans les labo de recherche. On travaille sur des domaines pointus et donc l'audit n'est pas facile. On tourne assez rapidement sur toujours les mêmes personnes.

Sinon, je ne connais pas du tout OpenSSL sauf en tant que simple utilisateur lambda. Je vois juste que c'est un composant fondamental et qu'il y a régulièrement des bogues. En fait, je trouve dommage qu'OpenSSL et que GnuTLS ne soit pas plus interchangeable.

Enfin, j'ai essayé de faire une liste de type checklist des bonnes pratiques pour ce genre de composant. Cette checklist est bien sur à améliorer.

Concernant plus spécifiquement le code du bogue debian, je crois me souvenir que la ligne capitale qui a été retirée n'étais pas spécialement commentée et surtout, qu'il y avait un certain nombre d'appel du "même" type. C'est en ce sens la qu'il y a peut-être une amélioration à voir.

Ce qui prouve au moins une chose, que malgré la bourde du mainteneur debian, introduire un bogue dans ce genre de programme peut être très difficile à déceler. Il faut donc que ce genre de programme lié à la sécurité valide les critères suivants :

- toujours faire auditer le code par des personnes extérieures

- passer tous les tests des compilateurs (et équivalent : valgrind...) sans aucun warning

- avoir un code très propre et bien documenté aux passages critiques

- avoir une API simple et claire

- avoir une batterie de test la plus large possible

Malgré cela, on n'est pas à l'abris d'un bogue subtile. Pour revenir au cas d'openssl, le développeur debian a fait une bourde mais je le projet openssl ne passe pas non plus le genre de critère que je viens d'énoncer.

Dans le cas de debian, le problème était sur le PID... Pour détecter cela, il faudrait lancer des tests sur n machines virtuelles vierges que l'on démarre puis lance le test dessus.

Sur la version de debian, si tu lançais 10 générateurs, tu ne voyait pas le problème...

Bref, il faut lancer dans ces cas là des tests sur un cluster (virtuel ou physique).

OK, refaire la même liste est très pratique mais il y a plein de cas ou on s'en fou. Par exemple pour marquer les paquets TCP/IP.

Pourquoi ne pas introduire tous les x pas de temps, x aléatoire, la température du CPU dans la formule ? Cela rajouterais un aléa quasi imprévisible et éviterait même au "propriétaire" de rejouer la séquence.

> tout le monde s'en fout!

Non, on ne s'en fout pas mais tu ne peux pas vivre en pensant 24h sur 24 à toute la misère dans le monde. Certaines personnes le peuvent mais pas toutes.

Donc on y pense souvent mais notre cerveau a besoin aussi de rigoler, de plaisanter... C'est pas incompatible, au contraire. Cela signifie que malgré la misère, l'homme est capable de construire des îlots de bonheur.

Bref, soutenir la cause tibétaine et ne pas y penser en permanence ne me semble pas incompatible avec l'envie de construire pour ses enfants un monde correct.

> Chirac quand quelques kanaks ont eu des velléités d'autonomie ? Il a tiré dans le tas.
> Depuis black-out total, ou presque, circulez, y a rien à voir

Depuis, il y a eu Rocard qui est passé par là et qui a réglé le problème de manière posé et a mis les partis en présence d'accord sur une période transitoire et le conflit s'est dégonflé.

Il ne faut donc pas tout mélanger...

-3- C'est une machine à registre

-4- C'est un projet communautaire

-5- Elle est très jeune mais déjà plus de 60% de perl6 tourne dedans.

Bref, elle entre dans sa phase finale comme perl6... Normalement, d'ici 1 an, les bogues majeurs empêchant son utilisation dans des projets majeurs devraient être corrigés. Le but de l'année qui vient est donc qu'un maximum de projet ambitieux (comme perl, python, ruby...) porte leur langage sous parrot pour la corriger.

Enfin, moi, c'est free qui refuse les courriels qui viennent des serveurs de chez Amen... J'ai demandé a Amen de faire quelque chose mais c'est comme si je ne demandais rien. Ils sont polis mais rien ne se passe. Vive l'herbergement mutualisé !

Je viens d'aider un copain qui avait un problème sur pam_mount suite a un upgrade du système. Et bien le format XML de ce truc est une horreur (erreur serait plutôt le mot). On se demande si les mecs qui ont pondu ce code sont administrateurs systèmes ou si ce ne sont que des développeurs qui 'pissent' du code au kilomètre !

Pour ceux qui ne voit pas de quoi je parle, sur une debian, le fichier en question est :


/etc/security/pam_mount.conf.xml

Merci.

Je me rappelle que Keith Packard annonçant après plusieurs mois de boulot qu'on ne pouvait pas améliorer la latence et le traffic d'X-Windows. Que tout ce que son équipe avait réussi en optimisant ici ou la le code était du même ordre de grandeur que la compression gzip réalisée par ssh avec l'opion -C. Bref, il concluait que le protocole X n'avait pas été conçu pour les faibles bandes passantes et qu'il n'y avait pas grand chose à y faire...

Puis, peu de temps après, No-Machine sortait NX qui permettait de faire du X sur des liaisons ADSL ! Personne n'y a cru mais on avait tous tords... NX marche super bien.

Bref, tout cela pour dire que bouffer du CPU pour compresser par gzip les fichiers XML tout cela parce qu'on pense que le XML ASCII, c'est génial et qu'on fera pas mieux, comme toi, je ne suis pas d'accord.

Il est bien plus rentable de passer des tableaux de nombres réels via HDF5 ou NetCDF qu'en XML ou il faut les écrire avec la quinzième décimale et ou cela prend un place folle et n'est pas du tout optimale pour le transfert.

Contrairement à NetCDF très orienté tableau, le format HDF5 permet de stocker une structure arborescente. C'est pour cela que j'ai parlé de lui. Ce serait intéressant d'avoir sur ce genre d'outil un portage de l'API XML, rien que pour voir.

Par rapport a NX, cela donne quoi ? Pourquoi ne pas avoir intégré NX dans Xorg ? NX est déjà libre et opérationnel même s'il est parfois casse pied à mettre en oeuvre car pas toujours bien intégré au reste.

Que ceux qui mon moissé explique leur position !

Le XML n'est qu'une manière d'écrire un arbre. Si sa principale utilisation est dans le dialogue inter-machine, autant avoir un format binaire NORMALISE. Ensuite, avec un petit utilitaire, tu peux transformer cet arbre binaire en arbre XML et réciproquement.

Bref, je ne vois pas ou l'idée d'avoir un XML binaire est une mauvaise idée. Au contraire. A partir du moment ou on manipule l'arbre XML via des API normalisé, il suffit d'utiliser les mêmes API sur le format binaire. En plus, avec un format binaire, on est obligé de passer par les API et c'en est finit du XML non valide (type XHTML).

Ce qui est dommage, c'est que quitte a faire un format pour la machine, autant faire un format binaire plus performant a tout les égards et qui ferait la même chose. HDF par exemple ou un équivalent.

Bref, on a mis des millions d'heure de travail humaine pour un truc qui finalement est surtout utilisable par la machine mais celle-ci travaille bien mieux en binaire qu'en ASCII... On aurait mis cette énergie sur HDF (ou équivalent) qu'on aurait des programmes bien plus performant de nos jours.

C'était fonctionnel avant ce soir ;-) Je travaille depuis 1996 a 95% sur du Linux (le restant étant lorsque je dépanne ;-)) et en 1996, il n'y avait pas encore de boite derrière. Linux était déjà parfaitement fonctionnel pour un tas de chose. Lorsque je vois les problèmes actuels sur ma lenny parce que ldap merdouille au démarrage (il y a une solution), les clefs USB merde à cause qu'udev et hal ne tienne pas compte de pam_group... Bref, on a compliqué la partie logiciel a parfois en perdre de la simplicité d'UNIX !

A l'époque, je préférais mon bureau fvwm à un Windows 95 !

Attention, ton script ne marche pas en interactif. En effet, les règles par défaut bloque la connexion... En script cela marche car la connexion est coupé mais avant que ssh coupe la connexion via un timeout et donc que le noyau tue ton script, celui-ci est finit.

Bref, je n'aime pas les scripts de firewall qui joue sur les timeout système pour leur mise en place. J'aime bien pouvoir faire un copier coller et que les choses ait exactement le même comportement. Dans mes scripts à moi, je comme TOUJOURS par les lignes suivantes :


# Policies
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT


Puis, j'accepte en entrée sortie (deux règles écrites explicitement) tout ce qui concerne la loopback (lo). Dans ton script à toi, il n'y en a qu'une car il y a une règle implicite sur la loopback. Je n'aime pas les règles implicites...

Enfin, je finit sur le bas du script par les règles par défaut définitive


iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP


En effet, j'écris aussi des règles explicites sur la chaîne OUTPUT. Je trouve plus clair d'écrire à coté des règles d'entrée INPUT le correspond pour la sortie OUTPUT que de laisser tout sortir.

Moi, la révélation, je l'ai eu avec le Forth car avec lui, tu reconstruis le langage lui même... A coté, le C, c'est pauvre ;-)

J'ai pas le souvenir de cette annonce par Intel. Lien ?

J'étais resté sur le rapprochement fait par intel entre le x86_64 et l'Itanium qui devrait partager le même socket l'an prochain afin de pouvoir avoir des cartes mères avec l'un ou l'autre des processeurs.

Aujourd'hui, on ne sais pas encore faire de machine SMP a 1024 coeurs x86_64 alors qu'avec l'Itanium oui.

Va faire un tour dans le code de zoppe -> []

Si GCC devient plus intelligent dans cette version (gain de 20% annoncé), est-ce que gcc va rattraper son retard sur icc pour l'architecture Itanium. En effet, pour cette architecture, le microprocesseur execute les instructions dans l'ordre d'arrivée et c'est au compilateur d'être intelligent. L'idée, pas idiote développé par Intel, est d'éliminer des milliers de composants du microprocesseur dédié à l'ordonancement pour les remplacer soit par du cache, soit par de la puissance de calcul.

Le revers de la médaille est d'avoir un bon compilo et que l'architecture interne des versions d'Itanium ne change pas trop. Vu la cadence de sortie de celui-ci, il n'y a pas de risque !

A noter que depuis la lenny, il ne faut plus dire 5.0r2 mais 5.0.2 !

En effet et c'est nouveau, le fichier /etc/debian_version est mis à jour ce qui n'était pas le cas avant des versions en r...

En pratique, cela ne change rien mais signifie simplement que la machine est à jour avec le dépot debian. C'est plus pratique comme manière de faire et plus 'pro' que l'ancienne appellation r2, r3...

Intégré ne veut pas non plus dire refaire la roue. Ce qui est important, c'est que si le code n'est pas compilé en statique, les bibliothèques sont partagés (si elles sont utilisés ailleurs).

Comme je ne pense pas que mozilla a tout recodé dans son coin, il devrait y avoir du partage dans l'air... lorsque les distributions auront intégré cette version de mozilla.

> Bref, quand on ne sait pas, on évite de lancer des remarques comme celles là.

Parce que toi, tu ne dis jamais de bêtises ! Contrairement à toi, moi quand un tube fait sa décharge, je ne suis pas à l'aise. Je ne trouve pas que ce soit un comportement raisonnable même si d'après toi, il n'est pas dangereux.

Ensuite, j'ai pas dis que les écrans plat étaient mieux. J'ai dis que je n'en donnais pas car je n'en avais pas que l'on ne se servaient plus. Les écrans que nous donnons sont des tubes et en général vieux de plus de 6 ans... Je le vois bien que les écrans plats vieillissent pas si bien que cela.

Enfin, pour moi, un écran flou est dangereux... car je ne pense pas que cela soit bien pour la vue. Mais manifestement, nous n'avons pas le même point de vue !

Tu remarqueras que j'ai mis un SI en grand et que je ne participe pas directement à se genre d'opération. Cependant, je donne tout mon vieux matos a une assosiation qui en recycle une partie pour les enfants en faisant ce travail sur la qualité du matériel à garder (car j'ai donné des écrans impeccables mais qui ne servaient plus).

Si tu sais, tant mieux, moi je ne sais pas. Je vois que les vieux écrans balancent une sacré décharge au démarrage et j'ai de moins en moins envie d'être en face de ces décharges.