Est-ce les logiciels faisant fonctionner Viadeo, LinkedIn, Facebook, etc. sont libres ? Est-ce l'API Google est libre ? Est-ce qu'au moins le code source est lisible ? En terme de sécurité, c'est un gain de temps d'avoir accès au code source pour l'auditer.
Je ne pourrai pas utiliser sereinement une telle application en ligne quotidiennement (Facebook ou autre) sans que plusieurs personnes aient audité le code.
Oui, je suis plutôt parano vis à vis des applications en ligne. Et ce n'est pas une crainte infondée. Le web est bourré de bugs en tout genre.
PS : Facebook c'est nul, ça marche pas sous Konqueror et machotte sous Firefox, boooouh !
(et si NuFW présente un jour une interface web de configuration de type "objet" j' y saute)
NuFW (fichier nuauth.conf) se configure avec un éditeur de texte pour le choix des modules et leurs options. Par contre, les ACLs (ce qui évolue le plus) se configurent avec l'interface web Nuface : http://software.inl.fr/trac/trac.cgi/wiki/EdenWall/NuFace
2007-02-20: First notification sent by Core.
2007-02-26: OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote (...)
2007-02-26: Core considers a remote denial of service a security issue (...)
2007-02-28: OpenBSD team indicates that the bug (...)
2007-03-05: Core develops proof of concept code (...)
(.......)
2007-03-09: OpenBSD team changes notice on the project's website to "security fix" (...)
Quoi ! NuFW troué ? INL, société éditrice de NuFW, a choisi la transparence : les bugs corrigés pouvant affecter la sécurité sont marqués « correctif de sécurité ». Voici l'ensemble des bulletins de sécurité depuis la naissance du projet (~5 ans) :
Seul un bug est exploitable : celui qui permet d'outrepasser les règles de filtrage basées sur le temps. Il faut comprendre ce que ça implique : si on bloque les connexions entre 22h et 5h, et bien un utilisateur pourra quand même se connecter la nuit. Mon dieu, c'est horrible ! Sauf que pour ouvrir une connexion, l'utilisateur doit déjà être authentifié et NuFW doit accepter son paquet (càd que l'admin autorise explicitement le flux, ce qui n'est pas autorisé est bloqué par défaut).
Il ne faut penser que la sécurité d'un logiciel repose sur le nombre de bulletins de sécurité. Beaucoup d'éditeurs (allez, citons Microsoft au pif) corrigent silencieusement des bugs (parfois critiques) dans des mises à jour sans en informer l'utilisateur. Sauf qu'avec une analyse différentielle, on peut retrouver ce genre de magouille... Et il y a toujours un grand débat entre « bug » et « vulnérabilité ». Relisez l'histoire du dernier bug IPv6 pour vous poiler :-)
À chaque sortie d'une nouvelle console de jeu, une rumeur est lancée par son constructeur : « cette console est tellement puissante qu'on peut fabriquer des missiles / fabriquer des bombes nucléaires / faire du café (!) / etc. ». Mais là je ne pense pas que ça vienne d'ATI ou Nvidia, mais d'une personne un peu parano et surtout mal informée ;-)
« Problème : les GPU cassent trop rapidement les mots de passe » : ça fait plusieurs années que les GPU ont été détournés de leur usage initial (calcul purement graphique) pour en faire n'importe quoi. Voir http://www.gpgpu.org/ pour s'en convaincre. Un ami dans un labo de recherche aux USA utilise des clusters de GPU pour créer de gros réseaux de neurones.
Tous les algorithmes de hachage ne naissent pas égaux face à John The Ripper :
Benchmarking: Standard DES [48/64 4K]... DONE
Many salts: 217523 c/s real, 231407 c/s virtual
Only one salt: 204928 c/s real, 217084 c/s virtual
Benchmarking: BSDI DES (x725) [48/64 4K]... DONE
Many salts: 7166 c/s real, 7591 c/s virtual
Only one salt: 6624 c/s real, 7016 c/s virtual
Benchmarking: NT LM DES [48/64 4K]... DONE
Raw: 1446553 c/s real, 1693856 c/s virtual
Blowfish : ~200 essais par seconds versus NT LM 1446553 essais/seconde. Il me semble que NT LM soit l'ancien format de mot de passe qui tend à disparaitre. Sauf qu'en pratique, ils sont encore disponibles quand on bidouille un peu... http://actes.sstic.org/SSTIC07/Authentification_Windows/
Les « RainbowTables » (tables arc en ciel) permettent de précalculer les mots de passe lorsqu'ils ne sont pas salés. L'ajout de sel rend RainbowTables inefficace. De plus, l'utilisation de caractères spéciaux (ne serait-ce qu'un lettre accentuée) les rend aussi inefficaces.
Conclusions : les GPU sont plus puissants, c'est une bonne chance, on pourra bientôt s'en servir pour éviter que .NET râme trop. Un mot de passe doit être long, utilise plusieurs jeux de caractères (lettres minuscules, majuscules, chiffres voir aussi signes de ponctuations, accents, etc.).
Signé Victor, social engineering specialist (Because there is no patch against human stupidity)
On voit que FreeBSD pousse toujours plus loin le réseau qui va toujours plus vite tout en gagnant en fonctionnalité (trunk, IPv6, etc.). Mais il y a énormément d'autres nouveautés comme un nouveau malloc() plus rapide en mono-CPU mais surtout en beaucoup-de-CPU. Et un nouveau ordonnanceur de processus... Que du bon.
Je suis l'actualité de FreeBSD de loin, mais je ne l'ai jamais vraiment utilisé. Un jour je retesterai peut-être :-)
Je trouve ça affligeant de s'émerveiller devant la correction d'un "bug" aussi vieux Netscape 1.0 (allez, Phoenix 0.1 :-)). Quand j'ai migré de Gnome à KDE, j'étais très heureux d'avoir un navigateur web intégré au bureau :
* boutons KDE
* barre de défilement KDE
* dialogue du choix de fichier KDE
* correcteur orthographique et recherche dans les "textarea"
* etc.
Grâce au SVG, Firefox bouffe 100% du CPU quand on déplace la souris au dessus cette carte de suisse. Donc pour répondre à la question : « OUI, Firefox est enfin au niveau de Flash ».
En pendant ce temps, la dernière Ubuntu propose d'installer Gnash...
Dommage de ne pas être migré vers COBOL.NET plutôt que Java. Il faudrait voir un peu plus sur le long terme, dotNET a un avenir tout tracé (supporté par Microsoft, marque de confiance) alors que Java est tombé dans le côté obscur de la force (contaminé par le virus GPL). Java petit à petit va éclater en multiple versions incompatibles entre elles, alors que dotNET est certifié Microsoft, preuve que le programme va fonctionner sans problème.
Dans l'idéal un snippet réalisé par un allemand devrait être accessible au français et réciproquement.
Non, j'ai dit le contraire : j'aimerai que ça soit impossible :-) Quand on cliquerait sur le drapeau « Deutsch », les snippets francophones disparaitraient et seuls ceux en allemand seraient visible. Je pars du postulat qu'il faut savoir lire l'allemand pour comprendre un code écrit en allemand. Et dit encore d'une autre manière : un pur francophone ne sera que pollué par les codes écrits dans une langue étrangère.
Comme le dit crétin.fr : « Téléphoner à l'étranger ça sert à rien, parce qu'à l'étranger ils parlent l'étranger ».
Voilà, je pense que mon argumentation est irréfutable ;-)
P.S. : S'inspirer de Wikipédia avec les liens interwikis ;-)
ICAP est un protocole utilisé par les logiciels de cache web (essentiellement HTTP et SMTP). Exemple de logiciel qui l'utilise : Trend InterScan (anti-virus). Lire ICAP pour les détails.
C'est une très bonne nouvelle que Squid le supporte. Apparemment, ça fait pas mal de temps qu'ils bossent sur le support d'ICAP.
« le melange francais/anglais n'aide pas non plus (dans les tags, dans le descriptif) »
J'ai posté quelques bouts de code pour tester, et c'est vrai que la mélange des langues (français et anglais) est troublante. Il faudrait pouvoir indiquer la langue du code et que ça soit le 1er critère de sélection. Comprendre que (par exemple) l'affichage des tags sur la page d'accueil dépendrait de la langue choisie. À la limite, il faudrait permettre de soumettre des tags dans sa langue maternelle + en anglais... mais avoir plusieurs versions, ça devient compliqué pour l'utilisateur.
Sinon, j'ai vu le tag "fuzzer" mais quand j'ai cliqué, y'avait aucun code associé :-( Je supose que c'est un code privé. Si c'est le cas, il faudrait ignorer ses tags dans l'affichage des tags...
Plus un ordinateur va vite, plus les langages de programmations peuvent gagner en abstractions. Les premiers ordinateurs étaient programmés en langage machine et on était limité aux spécficiations de la machine.
Si on observe l'évolution du langage Python, on peut voir les objets de haut niveau naître petit à petit. Python 2 permet de manipuler des caractères plutôt que des octets ('unicode' vs 'str') et Python 2.4 permet enfin d'avoir des nombres entiers sans limite débile (et source de nombreux bugs) à quelques milliards ('long' vs 'int'). D'ailleurs, Python 3000 va utiliser les types de haut niveau par défaut : "abc" désigne un chaîne de vrais caractères (et non pas d'octets comme en C) et les types int & long fusionnent.
C'est pas spécifique à Python, la programmation orientée objet est plus lente qu'un programme cablé en dur (du C par exemple), mais aujourd'hui on peut se permettre des perdre quelques pourcents de CPU et de mémoire à l'exécution pour accélérer le temps de développement.
À mon avis, les langages de programmations doivent monter en abstraction. Le but ultime étant d'écrire un programme dans sa langue maternelle... comme ce qui est présenté dans ce journal... sauf que je doute que ce jeu pacman soit jouable (c'est pas encore au point) ;-)
Quand la table des connexions grossit, conntrackd va prendre jusqu'à 50% de CPU. Pablo travaille sur ce point noir, et il sera sûrement résolu à court terme.
Autoconf offre différentes macros pour tester la présencer d'une bibliothèque, fonction, symbole, etc. Par contre, le comportement en cas de succès ou d'échec est libre. C'est au programmeur de choisir l'action réalisée, souvent un appel à AC_ERROR() qui va afficher un message et tout arrêter. En stockant le résultat de chaque test, on peut appeler AC_ERROR() tout à la fin. C'est ce que fait un bon configure.ac. Par contre, je sais pas s'il existe des méthodes propres pour le faire. Exemple de configure.ac utilisant des bidouilles pour arriver à ses fins : http://software.inl.fr/trac/trac.cgi/browser/mirror/edenwall(...)
Tous les messages sont affichés d'un coup, et le script s'interrompt une fois tous les messages affichés. Ca marche bien quand les modules peuvent être testés un par un. Exemple : rien ne sert de vérifier que les modules Gnome sont présent si X11 et/ou Gtk sont absents.
La PEP 3118 a eu sa branche Subversion : « py3k-buffer ». Travis a fini son travail et a mergé avec trunk mi-août (2007, ça fait donc parti de Python 3.0a1).
La PEP 3141 dépendait de la PEP 3119 (classe abstraite) qui a été implémentée. J'ai vu passer plusieurs patch pour cette PEP mais elle ne semble pas encore implémentée, ça avance doucemennt.
En tout cas, cette version s'annonce comme un mal de tête énorme pour tous les créateurs de bibliothèques, qui devront pendant une période de temps importante (python 2.3 est encore utilisé énormément, voir 2.2) fournir 2 versions de leur code...
Pour les modules écrits entièrement en Python, l'outil 2to3 s'occupe de convertir automatiquement tout le code. Il n'y a rien à faire. Pour les modules écrit en C, je ne sais pas. Je pense que d'avec des #ifdef, on doit pouvoir s'en sortir.
Quand on voit le mal que les core développeurs ont à porter les bibliothèques internes (cf email), il y a de quoi s'inquiéter.
J'ai aidé à porter le module email. Son gros défaut est qu'il mélangeait allègrement octet et caractère, chose totalement fausse d'un point de vue conceptuel. Disons que ça marche (en Python2), mais que le comportement est parfois inattendu...
Un gros travail a été fait sur le module et il a été intégré de justesse à la version alpha 1.
Porter un module pour Python3 implique de recadrer certaines choses, et ça va dans le bon sens.
Casser toute la compatibilité d'un coup n'a aucun sens.
Comme je l'ai déjà expliqué ça et là, les changements brisant la compatibilité est d'éviter les erreurs de programmation.
Exemple 1
Mélanger des octets (str) et caractères (unicode) est source de bugs difficile à corriger. Python2 autorise la comparaison entre un octet et un caractère, ce qui conceptuellement n'a aucun sens. Python3 lance une erreur TypeError (can't compare bytes and str).
Exemple 2
0666 est lu comme 438 par Python2, sauf que ça peut dérouter les débutants qui saisissent 001, 002, (...), 008 => SyntaxError. Python3 exige le préfixe « 0o » (zéro, lettre O) : 0o666.
Exemple 3
Les méthodes values() et items() d'un dictionnaire sont des itérateurs. Ceci évite que « for key, valeur in data.items(): ... » ne crée une liste temporaire qui peut peser lourd en mémoire, prend de temps à être créée. En plus, si ça se trouve la boucle va être interrompue à la 2e itération ! On pourra toujours obtenir une liste mais avec la syntaxe générique « items = list(data.items()) ».
Exemple 4
De nombreux ajouts visent à durcir les contrôles du typage. L'annotation des fonctions permettra d'indiquer le protoype d'une fonction et les classes abstraites peuvent servir d'interface.
Plutôt que d'être taquin pasBill pasGates, pourquoi tu n'as pas écrit une version francophone directement car tu sembles apparement être fluent en anglais ? Cela servirait à tout le monde.
# Licence de tout ce bazar ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche OpenSocial, un pas de plus vers une « société des réseaux sociaux ». Évalué à 2.
Je ne pourrai pas utiliser sereinement une telle application en ligne quotidiennement (Facebook ou autre) sans que plusieurs personnes aient audité le code.
Oui, je suis plutôt parano vis à vis des applications en ligne. Et ce n'est pas une crainte infondée. Le web est bourré de bugs en tout genre.
PS : Facebook c'est nul, ça marche pas sous Konqueror et machotte sous Firefox, boooouh !
[^] # Re: Intéressant !
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie d'OpenBSD 4.2. Évalué à 2.
NuFW (fichier nuauth.conf) se configure avec un éditeur de texte pour le choix des modules et leurs options. Par contre, les ACLs (ce qui évolue le plus) se configurent avec l'interface web Nuface :
http://software.inl.fr/trac/trac.cgi/wiki/EdenWall/NuFace
[^] # Re: Intéressant !
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie d'OpenBSD 4.2. Évalué à 3.
Avec l'URL c'est plus utile :
http://www.coresecurity.com/?action=item&id=1703
Court extrait :
2007-02-20: First notification sent by Core.
2007-02-26: OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote (...)
2007-02-26: Core considers a remote denial of service a security issue (...)
2007-02-28: OpenBSD team indicates that the bug (...)
2007-03-05: Core develops proof of concept code (...)
(.......)
2007-03-09: OpenBSD team changes notice on the project's website to "security fix" (...)
[^] # Re: Intéressant !
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie d'OpenBSD 4.2. Évalué à 5.
http://secunia.com/advisories/17754/ - NuFW Packet Parsing Denial of Service Vulnerability (2005-11-29) => DoS
http://secunia.com/advisories/19046/ - NuFW TLS Socket Handling Denial of Service (2006-02-28) => DoS
http://secunia.com/advisories/26546/ - NuFW Time Based Filtering Rules Security Bypass (2007-08-21) => troué
http://secunia.com/advisories/27442/ - NuFW "samp_send()" Buffer Overflow Vulnerability (2007-10-30) => Dos
Seul un bug est exploitable : celui qui permet d'outrepasser les règles de filtrage basées sur le temps. Il faut comprendre ce que ça implique : si on bloque les connexions entre 22h et 5h, et bien un utilisateur pourra quand même se connecter la nuit. Mon dieu, c'est horrible ! Sauf que pour ouvrir une connexion, l'utilisateur doit déjà être authentifié et NuFW doit accepter son paquet (càd que l'admin autorise explicitement le flux, ce qui n'est pas autorisé est bloqué par défaut).
Il ne faut penser que la sécurité d'un logiciel repose sur le nombre de bulletins de sécurité. Beaucoup d'éditeurs (allez, citons Microsoft au pif) corrigent silencieusement des bugs (parfois critiques) dans des mises à jour sans en informer l'utilisateur. Sauf qu'avec une analyse différentielle, on peut retrouver ce genre de magouille... Et il y a toujours un grand débat entre « bug » et « vulnérabilité ». Relisez l'histoire du dernier bug IPv6 pour vous poiler :-)
[^] # Re: Comm
Posté par Victor STINNER (site web personnel) . En réponse au journal Bientot l'interdiction des cartes graphiques puissantes?. Évalué à 10.
« Problème : les GPU cassent trop rapidement les mots de passe » : ça fait plusieurs années que les GPU ont été détournés de leur usage initial (calcul purement graphique) pour en faire n'importe quoi. Voir http://www.gpgpu.org/ pour s'en convaincre. Un ami dans un labo de recherche aux USA utilise des clusters de GPU pour créer de gros réseaux de neurones.
Tous les algorithmes de hachage ne naissent pas égaux face à John The Ripper :
Blowfish : ~200 essais par seconds versus NT LM 1446553 essais/seconde. Il me semble que NT LM soit l'ancien format de mot de passe qui tend à disparaitre. Sauf qu'en pratique, ils sont encore disponibles quand on bidouille un peu...
http://actes.sstic.org/SSTIC07/Authentification_Windows/
Les « RainbowTables » (tables arc en ciel) permettent de précalculer les mots de passe lorsqu'ils ne sont pas salés. L'ajout de sel rend RainbowTables inefficace. De plus, l'utilisation de caractères spéciaux (ne serait-ce qu'un lettre accentuée) les rend aussi inefficaces.
Conclusions : les GPU sont plus puissants, c'est une bonne chance, on pourra bientôt s'en servir pour éviter que .NET râme trop. Un mot de passe doit être long, utilise plusieurs jeux de caractères (lettres minuscules, majuscules, chiffres voir aussi signes de ponctuations, accents, etc.).
Signé Victor, social engineering specialist (Because there is no patch against human stupidity)
# Très intéressant
Posté par Victor STINNER (site web personnel) . En réponse au journal FreeBSD 7.0 Beta 1 est sortie. Évalué à 3.
http://ivoras.sharanet.org/freebsd/freebsd7.html
On voit que FreeBSD pousse toujours plus loin le réseau qui va toujours plus vite tout en gagnant en fonctionnalité (trunk, IPv6, etc.). Mais il y a énormément d'autres nouveautés comme un nouveau malloc() plus rapide en mono-CPU mais surtout en beaucoup-de-CPU. Et un nouveau ordonnanceur de processus... Que du bon.
Je suis l'actualité de FreeBSD de loin, mais je ne l'ai jamais vraiment utilisé. Un jour je retesterai peut-être :-)
[^] # Re: KDE et Konqueror
Posté par Victor STINNER (site web personnel) . En réponse au journal Firefox 3.0 utilisera enfin vos thèmes GTK !. Évalué à 2.
http://www.haypocalc.com/tmp/konqueror_qt.png
# KDE et Konqueror
Posté par Victor STINNER (site web personnel) . En réponse au journal Firefox 3.0 utilisera enfin vos thèmes GTK !. Évalué à 10.
* boutons KDE
* barre de défilement KDE
* dialogue du choix de fichier KDE
* correcteur orthographique et recherche dans les "textarea"
* etc.
Visuellement, Konqueror s'intègre très bien dans KDE.
http://www.haypocalc.com/tmp/konqueror.png
Je serai très heureux pour les utilisateurs de Gnome que KHTML puisse utilise Gtk (projet en développement...).
# Oui
Posté par Victor STINNER (site web personnel) . En réponse au journal Le SVG peut-il remplacer le flash ??. Évalué à 5.
En pendant ce temps, la dernière Ubuntu propose d'installer Gnash...
# Entropie, logique réversible, processeur asynchrone et quantique, etc.
Posté par Victor STINNER (site web personnel) . En réponse au journal Une équivalence entre l'énergie et l'information ?. Évalué à 2.
http://www.haypocalc.com/blog/index.php/2007/10/16/79-revers(...)
Rouvrir un journal serait peut-être plus intéressant, mais je n'ai pas envie de traduire la syntaxe Dotclear en syntaxe linuxfr...
[^] # Re: Et dotNET alors ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol. Évalué à 3.
# Et dotNET alors ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol. Évalué à -2.
[^] # Re: cool
Posté par Victor STINNER (site web personnel) . En réponse au journal Mais c'est Ignobel. Évalué à 2.
[^] # Re: bonne idée
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de Friendsnippets. Évalué à 4.
Non, j'ai dit le contraire : j'aimerai que ça soit impossible :-) Quand on cliquerait sur le drapeau « Deutsch », les snippets francophones disparaitraient et seuls ceux en allemand seraient visible. Je pars du postulat qu'il faut savoir lire l'allemand pour comprendre un code écrit en allemand. Et dit encore d'une autre manière : un pur francophone ne sera que pollué par les codes écrits dans une langue étrangère.
Comme le dit crétin.fr : « Téléphoner à l'étranger ça sert à rien, parce qu'à l'étranger ils parlent l'étranger ».
Voilà, je pense que mon argumentation est irréfutable ;-)
P.S. : S'inspirer de Wikipédia avec les liens interwikis ;-)
[^] # Re: flash
Posté par Victor STINNER (site web personnel) . En réponse au journal La page la plus inutile qui soit !. Évalué à 2.
# ICAP
Posté par Victor STINNER (site web personnel) . En réponse au journal Squid 3.0 en Release Candidate. Évalué à 5.
C'est une très bonne nouvelle que Squid le supporte. Apparemment, ça fait pas mal de temps qu'ils bossent sur le support d'ICAP.
[^] # Re: bonne idée
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de Friendsnippets. Évalué à 2.
J'ai posté quelques bouts de code pour tester, et c'est vrai que la mélange des langues (français et anglais) est troublante. Il faudrait pouvoir indiquer la langue du code et que ça soit le 1er critère de sélection. Comprendre que (par exemple) l'affichage des tags sur la page d'accueil dépendrait de la langue choisie. À la limite, il faudrait permettre de soumettre des tags dans sa langue maternelle + en anglais... mais avoir plusieurs versions, ça devient compliqué pour l'utilisateur.
Sinon, j'ai vu le tag "fuzzer" mais quand j'ai cliqué, y'avait aucun code associé :-( Je supose que c'est un code privé. Si c'est le cas, il faudrait ignorer ses tags dans l'affichage des tags...
# On gagne en abstraction
Posté par Victor STINNER (site web personnel) . En réponse au journal Language naturel 2 python. Évalué à 8.
Si on observe l'évolution du langage Python, on peut voir les objets de haut niveau naître petit à petit. Python 2 permet de manipuler des caractères plutôt que des octets ('unicode' vs 'str') et Python 2.4 permet enfin d'avoir des nombres entiers sans limite débile (et source de nombreux bugs) à quelques milliards ('long' vs 'int'). D'ailleurs, Python 3000 va utiliser les types de haut niveau par défaut : "abc" désigne un chaîne de vrais caractères (et non pas d'octets comme en C) et les types int & long fusionnent.
C'est pas spécifique à Python, la programmation orientée objet est plus lente qu'un programme cablé en dur (du C par exemple), mais aujourd'hui on peut se permettre des perdre quelques pourcents de CPU et de mémoire à l'exécution pour accélérer le temps de développement.
À mon avis, les langages de programmations doivent monter en abstraction. Le but ultime étant d'écrire un programme dans sa langue maternelle... comme ce qui est présenté dans ce journal... sauf que je doute que ce jeu pacman soit jouable (c'est pas encore au point) ;-)
[^] # Re: Module owner
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Compte rendu en temps réel de l'atelier Netfilter 2007. Évalué à 3.
[^] # Re: Merci
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Compte rendu en temps réel de l'atelier Netfilter 2007. Évalué à 3.
# C'est à la charge du programmeur
Posté par Victor STINNER (site web personnel) . En réponse au journal (troll du vendredi) Configuration à l'envers ?. Évalué à 3.
http://software.inl.fr/trac/trac.cgi/browser/mirror/edenwall(...)
Tous les messages sont affichés d'un coup, et le script s'interrompt une fois tous les messages affichés. Ca marche bien quand les modules peuvent être testés un par un. Exemple : rien ne sert de vérifier que les modules Gnome sont présent si X11 et/ou Gtk sont absents.
[^] # Re: numpy integration?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de la version 3.0a1 du langage Python. Évalué à 2.
http://www.python.org/dev/peps/pep-0209/ -- Multi-dimensional Arrays
http://www.python.org/dev/peps/pep-3141/ -- A Type Hierarchy for Numbers
http://www.python.org/dev/peps/pep-0357/ -- Allowing Any Object to be Used for Slicing
http://www.python.org/dev/peps/pep-3118/ -- Revising the buffer protocol
La PEP 209 a été rejettée si j'ai bien compris.
Le PEP 357 a été implementée dans Python 2.5.
La PEP 3118 a eu sa branche Subversion : « py3k-buffer ». Travis a fini son travail et a mergé avec trunk mi-août (2007, ça fait donc parti de Python 3.0a1).
La PEP 3141 dépendait de la PEP 3119 (classe abstraite) qui a été implémentée. J'ai vu passer plusieurs patch pour cette PEP mais elle ne semble pas encore implémentée, ça avance doucemennt.
[^] # Re: Plusieurs bémols
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de la version 3.0a1 du langage Python. Évalué à 1.
Pour les modules écrits entièrement en Python, l'outil 2to3 s'occupe de convertir automatiquement tout le code. Il n'y a rien à faire. Pour les modules écrit en C, je ne sais pas. Je pense que d'avec des #ifdef, on doit pouvoir s'en sortir.
Quand on voit le mal que les core développeurs ont à porter les bibliothèques internes (cf email), il y a de quoi s'inquiéter.
J'ai aidé à porter le module email. Son gros défaut est qu'il mélangeait allègrement octet et caractère, chose totalement fausse d'un point de vue conceptuel. Disons que ça marche (en Python2), mais que le comportement est parfois inattendu...
Un gros travail a été fait sur le module et il a été intégré de justesse à la version alpha 1.
Porter un module pour Python3 implique de recadrer certaines choses, et ça va dans le bon sens.
[^] # Re: Plusieurs bémols
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de la version 3.0a1 du langage Python. Évalué à 3.
Comme je l'ai déjà expliqué ça et là, les changements brisant la compatibilité est d'éviter les erreurs de programmation.
Exemple 1
Mélanger des octets (str) et caractères (unicode) est source de bugs difficile à corriger. Python2 autorise la comparaison entre un octet et un caractère, ce qui conceptuellement n'a aucun sens. Python3 lance une erreur TypeError (can't compare bytes and str).
Exemple 2
0666 est lu comme 438 par Python2, sauf que ça peut dérouter les débutants qui saisissent 001, 002, (...), 008 => SyntaxError. Python3 exige le préfixe « 0o » (zéro, lettre O) : 0o666.
Exemple 3
Les méthodes values() et items() d'un dictionnaire sont des itérateurs. Ceci évite que « for key, valeur in data.items(): ... » ne crée une liste temporaire qui peut peser lourd en mémoire, prend de temps à être créée. En plus, si ça se trouve la boucle va être interrompue à la 2e itération ! On pourra toujours obtenir une liste mais avec la syntaxe générique « items = list(data.items()) ».
Exemple 4
De nombreux ajouts visent à durcir les contrôles du typage. L'annotation des fonctions permettra d'indiquer le protoype d'une fonction et les classes abstraites peuvent servir d'interface.
[^] # Re: et en français
Posté par Victor STINNER (site web personnel) . En réponse au journal Rigolons un peu avec ODF. Évalué à 2.