Victor STINNER a écrit 1632 commentaires

Perso j'aimerai beaucoup pouvoir échanger des fichiers en IPv6 avec Gajim. L'idée serait d'utiliser Jabber en IPv4 ou IPv6, qu'importe, mais que l'échange de fichier utilise IPv6 si on est derrière du NAT (ce qui arrive très souvent) : car l'IPv6 est souvent moins/pas filtré. On pourrait se passer d'un serveur proxy qui limite la bande passante (rajoute un intermédiaire uniquement utile pour contourner le NAT). À vrai dire, je pense à une Freebox.

Y'a pas que la taille qui compte, y'a aussi le diamètre.

Non pas forcément. H peut très bien être un interpréteur de commandes genre bash

Tu aurais un exemple de commande bash pour utiliser ton GPU ? Parce que là je suis très curieux de savoir comment on fait. Justement, je voulais dire qu'un programme qui utilise intensivement le GPU est détectable de par son comportement.

ce dernier n'etait pas activement exploite, raison pour laquelle on a prefere tester le patch plus longtemps

Je trouve cet argumentation irrecevable. Il faut attendre que la faille soit ACTIVEMENT exploitée pour qu'elle soit patchée ? Il y a un vrai marché noir des exploits : un acheteur pourrait très bien demander l'exclusivité et l'utiliser pour des cibles précises. Bien sûr, la personne qui découvre la faille peut aussi choisir de ne pas la diffuser et l'exploiter pour sa pomme. Microsoft attend que suffisamment de sociétés soient impactées pour patcher ?

Et non, si tu regardes les patchs kernel de Redhat par exemple (...)

Pourquoi tu te focalises sur RedHat, tu as un dent contre eux ? Est-ce que RedHat entre en concurrence avec Microsoft, c'est pour ça qu'il faut absolument trouver les défauts de cet OS ?

[au sujet du patchage de noyau à chaud] Bref, dans la majorite des cas, impossible.

Renseigne toi un peu au lieu de diffuser de fausses informations :
http://www.ksplice.com/cve-evaluation

Un étudiant motivé a réussi à tenir 2 ans sans rebooter tout en patchant son noyau (84% des patchs appliqués à chaud sans modif, et les autres avec modif). Il semble qu'une boîte ait été fondée autour de ce service qui se vend maintenant (tout en restant GPL).

la raison du groupement des patchs c'est justement que les entreprises le demandent (...) A chaque patch elles doivent revalider leurs applications, il est plus simple pour elles de le faire une fois pour tous les patchs que tous les 5 jours.

Je ne comprend pas en quoi c'est plus simple. Disons pour l'exemple qu'Ubuntu propose une mise à jour par jour et que Windows en propose 30 par mois (ce qui donne aussi 1 par jour). Bah si tu prends 3 jours pour étudier (tester/valider) une màj Ubuntu, tu seras exposé durant 3 jours à une faille donnée. Si tu prends 2 jours pour étudier les 30 màj Windows, tu seras exposé à 30 failles durant 2 jours. Je pense donc que Windows est plus longtemps exposés aux failles. J'ai pris des nombres un peu au pif juste pour illustrer mon idée.

Le travers de la solution Microsoft est que si une faille apparait le lendemain de la publication de toutes les màj, il faudra attendre un mois pour qu'elle soit corrigée. La période d'exposition à la faille est plus longue.

Il semble que Microsoft n'aime pas la mesure de la durée durant laquelle l'OS est exposé à une faille donnée. Je pense que justement avec cette mesure ils s'en sortent moins bien que les autres, or ça me semble être la plus proche de la réalité.

http://www.heise-online.co.uk/security/MS-Malicious-Software(...)

Avec la mise à jour du 10 décembre (2008), le Malicous Software Removal Tool (MSRT) s'est mis à détecter de faux positifs et proposer de supprimer les logiciels comme « Vegas Movie Studio Platinum 8.0 » ou « Microsoft Flight Simulator » (haha). Question qualité, c'est pas terrible.

Bon, si vous voulez rire un bon coup, lisez le billet de Sid sur le dernier Patch Tuesday qui est particulièrement gratiné :
http://sid.rstack.org/blog/index.php/311-patch-tuesday-grati(...)

« vingt-huit failles ; vingt-sept en exécution de code à distance ; (...) vingt-cinq sont jugées critiques ; (...) ; une est gratifiée d'un exploit depuis août dernier... »

Je préfère recevoir régulièrement les patchs tous les jours via apt-get qu'attendre un mois pour pousser une vingtaine de correctifs d'un coup. Et puis bon, sous Linux il est très rare d'avoir à rebooter un serveur pour appliquer un correctif de sécurité (même pour le noyau, on peut s'en passer !).

http://www.heise-online.co.uk/security/Microsoft-explains-th(...)

Microsoft a publié un correctif nombre dernier (2008) pour corriger une faille SMB sur l'authentification par le réseau connue depuis 2001. La justification de Microsoft : corriger la faille plus tôt aurait empêcher des applications comme Outlook de fonctionner. J'espère avoir bien résumé, suivez les liens pour les détails.

Bon, ça aurait été vraiment grave si la faille avait été exploitée, mais là ce n'est pas le cas. Quoique...
http://www.tarasco.org/security/smbrelay/

Pourquoi changer du code qui marche ? Les procédures de validation des programmes dans les banques sont longues. Alors si ça marche en COBOL, pourquoi migrer à quoi que ce soit d'autre ? En plus, il existe COBOL.NET, il est moderne ce langage !

Le noyau Linux-2.6.27.7 pour une meilleure prise en charge du matériel et autres fonctionnalités sympathiques.

Comme un déni de service local ? :-) Utilisez la version 2.6.27.8 ou ne prêtez pas votre ordinateur (ni accès physique, ni SSH).
http://linuxfr.org/~ptiseb/27618.html

--

Wicd a l'air séduisant. J'aime bien Network Manager, mais les clones motivent la concurrence, c'est chouette :-)

« un programme H qui tourne sur le CPU (la partie Hote) ... D'autre part, D ne peut pas faire d'appels système directement »

Hum, dans ce cas la partie H est un virus classique et je pense qu'il sera facile à identifier. Bref, rien d'intéressant ici. Je trouve les malwares utilisant la virtualisation plus rigolos.

De toute manière, les pirates développent rarement des malwares très intelligents. La plupart du temps, ils réutilisent des vieux virus et rajoutent des failles connues et déjà patchées. Mais ça fonctionne car sous Windows il est difficile d'avoir un OS 100% à jour (lire le rapport Secunia récent à ce sujet). Je veux dire qu'ils s'amusent pas à développer des solutions très pointues car :
- il a peu de développeurs capables de le faire (main d'œuvre chère)
- c'est moins fiable que du code courant (répandu et mieux testé)

Bien sûr, en théorie le virus ultime est très effrayant car il serait totalement indétectable et pourrait mettre le Terre à feu et à sang (revoir Die Hard 4 avec Bruce Willis, Matrix, etc.). Bon, dépêchez vous de troller car le LHC va bientôt être (re)mis en marche, faites gaffe de pas mettre les pieds dans un trou noir.

Les « magic quotes » sont une fausse sécurité qui pose plus de problèmes qu'elle n'apporte de solutions je trouve.

Il est possible d'injecter du SQL sans apostrophe grâce à la syntaxe 0x... pour noter les chaînes des caractères : LOAD_FILE(0x2F6574632F706173737764) lit le contenu du fichier /etc/passwd et ne contient pas d'apostrophe. De plus, cette protection a introduit une autre faille avec le charset Big5 (utilisé pour le mandarin) : la séquence d'octets (0xB3, 0x27) est échappée en (0xB3, 0x5C, 0x27), or 0xB35C est un caractère valide en Big5, et on obtient donc une apostrophe seule !
http://www.abelcheung.org/advisory/20071210-wordpress-charse(...)
http://www.haypocalc.com/blog/index.php/2008/01/26/124-faill(...)

Côté pratique, c'est emmerdant pour l'utilisateur qui voit « l\'église » ou encore « l\\'église ».

Vivement PHP6 qui supprimer cette FIB (fausse bonne idée). D'ailleurs, la doc PHP affiche un gros avertissement : « WARNING: This feature has been DEPRECATED and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged. ».

Python utilise UCS-2 ou UCS-4 en interne (selon des options de compilation). Cet encodage garantit un temps d'accès en O(1) à un caractère selon sa position, contrairement à UTF-* qui ont des temps d'accès en O(n). Pour les expressions régulières par exemple, je pense que ça accélère beaucoup :-) Pour UCS-2, si un essaye de créer un caractère hors de [0; 65535], une exception est lancée.

En attendant les paquets, j'ai pour habitude d'installer les vieilles et nouvelles versions (en développement) de Python dans /opt. Un bon vieux « ./configure --prefix=/opt/python26 » et voilà (Python se compile en 5 minutes à peu près). Pour lancer Python : /opt/python26/bin/python2.6 (ajouter /opt/python26/bin dans le PATH si besoin). Pour supprimer Python : rm -rf /opt/python26.

Bizzare, Java autorise ça depuis longtemps et pourtant je ne vois pas de projet libre écrit avec des identifiants en esperanto.

Modulo quelques adaptations, il est possible d'écrire du code qui fonctione sur Python 1.5 .. 3.0. Exemple trivial : « print("Hello World!") ».

>>>  =1
File "", line 1
 =1
^
SyntaxError: invalid character in identifier

Tous les caractères Unicode ne sont pas autorisés dans un identifiant.
http://docs.python.org/3.0/reference/lexical_analysis.html#i(...)

Petit rappel : Python 3.0 est basé sur Python 2.6. Donc entre 2.5 et 3.0, il y a toutes les nouveautés de Python 2.6 dont la liste est très longue ! Relire la dépêche Python 2.6 pour la peine :
http://linuxfr.org/2008/10/02/24556.html

En plus de ça, je trouve que la liste des nouveautés 3.0 donnerait presque envie de faire une croix sur Python2 ! Je pense par exemple à l'annotation des fonctions ou aux arguments sous forme de mot-clé uniquement (« def pouet(*, cle=42): ... »). Il y a aussi la syntaxe {1, 2, 3} pour les ensembles (set), les « compréhensions de dictionnaires », etc.

Pour l'instant, Python3 intègre toute la bibliothèque standard (moins les vieux modules supprimés). Les modules tiers vont migrer petit à petit. Pour certain (comme PyQt), ça risque de prendre beaucoup de temps car l'API C (certains modules Python sont écrits en C) a beaucoup changé.

Pour les modules écrit en pur Python, je trouve que la conversion est triviale ! L'outil 2to3 fait 90 à 100% du boulot. J'ai migré python-ptrace et Fusil (25.000 lignes de Python) en une après-midi.

Non c'est un vrai problème (qui est en discussion sur python-devel et qui selon moi est fondamental).

Effectivement, ce point épineux a provoqué des discussions assez houleuses sur la liste de diffusion. Il y a trois choses : sys.argv, noms des fichiers, et les variables d'environnement. Pour l'instant, tout est accessible en Unicode.

Pour les fichiers, j'ai écrit un patch pour pouvoir utiliser des noms de fichier sous forme d'octets. Ce travail a pris plusieurs mois mais a été intégré pour la sortie de la version 3.0 finale.

Pour les variables d'environnement (comme PATH), c'est en cours de discussion. Je pense que la version 3.1 pourra accéder aux variables d'environnement en tant qu'octets. Pour sys.argv, personne ne s'en est plaint (pas de bug ouvert, je crois) :-) Sûrement qu'à terme, il existera aussi une méthode pour accéder à la version en octets.

La solution que je déteste et que plusieurs personnes essayent à chaque fois de pousser, est de stocker des octets dans Unicode en utilisant un encodage spécial (ex: utiliser une plage réservée d'Unicode). Mais je ne comprend pas l'intérêt car on revient au status pourri de Python2 qui mélange octets et caractères, source de nombreux bugs. En particulier, le texte Unicode n'est plus interopérable :-/

À long terme, tous les systèmes utiliseront Unicode. Pour information, Windows utilise UTF-16 partout depuis très longtemps (Windows 98 je crois). Le problème est lorsqu'on mélange de vieilles partitions encodés avec des encodages différents. Il vaut mieux tout mettre en UTF-8 pour des raisons de simplicité. Python3 fait un pari sur l'avenir.

Note : Sur un système sain (UTF-8 partout), Python3 fonctionne à merveille ! C'est très agréable d'avoir de l'Unicode partout !

Le RSS Reader... (...) Un carnet d'adresse...

Tu as déjà essayé Akregator et KAdressBook ? Pour le carnet d'adresse : il est partagé avec Konversation (IRC), Kmail (mail) et Kopete (message instantanée). Du coup, tu peux voir la photo de tes amis dans IRC, l'état de présence dans l'entête des emails, etc. C'est bien intégré et très fonctionnel.

J'ai testé Lifeara sous Gnome, mais avec ~40 flux après 6 mois ça devient si lent que ça en est inutilisable. Il semble qu'il ne supprime jamais les anciens flux, même en changeant la limite. La recherche ne peut pas se faire un seul flux, elle est devient plutôt inutile du coup :-/ Autre gros défaut : impossible de savoir de quel flux vient un article !?

perso je préférai la version 3.0

Parce qu'il n'y a rien dans la syntaxe python pour déterminer explicitement le début et la fin d'un bloc.

Un automate peut quand même facilement les trouver. Python y arrive bien ;-)

Avec Python 2:

>>> print "a", "b"
a b
>>> print ("a", "b")
('a', 'b')

Je trouve ça moche : selon la présence de parenthèse ou non, le résultat est différent. Alors qu'habituellement, rajouter des parenthèses ne change rien. Exemple : « x = 1, 2 » et « x = (1, 2) » sont synonymes.

Ton argument est « avant c'était bogué, il faut que ça reste bogué ». Ça me fait penser aux bugs HTML d'Internet Explorer... Justement, Python3 fait table rase de vieilles horreurs pour homogénéiser le langage.

même bien indenté ton code peut ressembler à rien ( saut de 10 lignes, commentaires, lignes trop longues et autres, mélanges espace tabulation...

Tu peux tronquer les lignes trop longues, je vois pas le rapport avec l'indentation. Tu coupes là où tu veux et tu mets « \ » en fin de ligne (souvent, même pas besoin de l'antislash). Je ne connais pas d'outil pour ça, mais en même temps je n'ai jamais lu de tel code (mais vu le nombre de légendes, ça doit exister :-)). Je pense qu'il existe des outils pour faire ça.

Pour uniformiser espaces et tabulations, Python intègre l'outil tabnanny.

Le jours ou tu voudra rajouter une condition, tu vas sélectionner un paquet de ligne indenter, et au passage oublier une ligne...

Je pense qu'un bon éditeur Python sait trouver la fin d'un bloc. Perso je le fais à la main avec vim : sélection des lignes à indenter puis commande < ou >.

Bien sûr, si le bloc fait 934 lignes, c'est plus dur. Mais là il faudrait penser à nettoyer un peu le code :-)

L'horrible « print "a", » (notez la virgule à la fin) était plutôt sale, je préfère « print("a", end=' ') » ou print("a", end='') ».

La syntaxe « print >>sys.stderr, "bla" » était un cas très particulier en Python : seul print utilise cette syntaxe. Maintenant la syntaxe est uniforme : « print("bla", file=sys.stderr) ».

Le mot clé print empêchait de définir une méthode print dans une classe.

print ("a", "b") prêtait à confusion : c'est un tuple de deux valeurs ou deux valeurs ? (afficher "a b" ou "('a', 'b')" ?) Avec Python3, il n'y a plus de doute possible.

print n'était qu'une longue liste de cas particuliers foireux.