Victor STINNER a écrit 1639 commentaires

http://www.netsplit.com/2009/09/02/making-a-splash/ date du 2 septembre 2009. Au sujet de Plymonth, le backend "drm" a été crée le 28 septembre, et le backend "x11" le 4 octobre (après cet article).

Maintenant si on regarde le planning de Karmic (https://wiki.ubuntu.com/KarmicReleaseSchedule) :
* 3 septembre : Alpha 5
* 17 septembre : Alpha 6
* 23 octobre : Béta

Bien sûr, si Canonical avait investit plus dans Plymonth, les backends drm et x11 auraient été plus rapidement disponible, et pour être à temps pour Karmic.

Au sujet de setuptools, le projet a été forké après 2 ans d'inactivité de son auteur (P.J. Eby). Pourtant, il y avait des bugs dans setuptools, et je crois qu'il y avait même des patchs en attente.

Le français Tarek Ziadé a pris le taureau par les cornes en commençant par s'assigner mainteneur du module distutils (la brique sur laquelle repose setuptools, et qui sert pour installer tous les projets Python). Ce n'est pas une tâche facile car le projet distutils est très mal testé (couverture de code à hauteur de 20-30% quand tarek est arrivé), pas mal bogué et il y avait des dizaines tickets en attente dans le bug tracker. Bref, tarek a fait un énorme travail sur distutils ces derniers mois.

--

C'est indécent, mais il ne s'en est pas arrêté là le coquin. Il s'est attaqué à bien pire, à setuptools. Comme le mainteneur de setuptools semble plutôt frileux niveau contributions et ouverture sur la communauté, tarek a forké le projet sous le nom Distribute.

Distribute fonctionne plutôt bien et est développé par plusieurs personnes, dont deux développeurs "core" de Python (gros gage de qualité). Le projet est hébergé là :
http://bitbucket.org/tarek/distribute/

La documentation est directement sur le site python.org, preuve que le projet est supporté par les développeurs core de Python :
http://packages.python.org/distribute/

La semaine dernière il y a même eu un sprint en ligne pour booster le projet. Pour suivre l'évolution de Distribute, le mieux est le blog de Tarek :
http://tarekziade.wordpress.com

Au contraire, setuptools a toujours voulu rester séparé de Python, et n'a rien fait pour être intégré ou bien améliorer distutils (corriger le mal (distutils est une horreur !) à la source).

--

Pendant ce temps, le mainteneur de setuptools sort de son hibernation et attaque directement tarek et son projet Distribute, en disant qu'il est plus bogué que setuptools (ce qui est une abération). Il dit également qu'il était parfaitement ouvert aux contributions externes, ce qui semble bien étonnant quand on sait qu'en 2 ans il n'y a eu aucune release.
http://dirtsimple.org/2009/10/that-wasn-so-difficult-was-it.(...)

Il en profite pour se plaindre que Python 2.6.3 a cassé SON projet (setuptools, vilain Python !), et se vante d'avoir contourné le bug.

--

Des liens sur distutils, Distribute et setuptools :
http://pvergain.wordpress.com/package-management/

Je vous laisse lire les archives de la liste de diffusion distutils-sig, mais moi j'ai fait mon choix : Distribute ! Et je suis très content que Tarek mette un coup de pied dans la fourmilière.

LLVM est sous licence BSD, est plus jeune (ne traine pas du vieux code depuis 1985 comme gcc), sait faire des optimisations dont GCC est incapable (parce que GCC est difficile à modifier, plus gros, plus complexe), possède un compilateur à la volée (JIT). Il me semble que LLVM est plus générique que GCC (gère plus de langages et des langages plus variés) : LLVM est par exemple utilisé pour compiler les shaders pour GPU avec Gallium ou bien pour compiler du Python à la volée.

J'ai l'impression que LLVM est plus conçu comme une bibliothèque intégrable à un projet existant qu'un programme en ligne de commande.

Le problème d'un compilateur à la volée est que c'est difficile à déboguer. La dernière version d'Unladen Swallow (qui utilise LLVM), la 2009Q3, inclut de symbole de debug pour gdb 7.0 :

"The Unladen Swallow team added support to gdb 7.0 that allow JIT compilers to emit DWARF debugging information so that gdb can function properly in the presence of JIT-compiled code. This interface should be sufficiently generic that any JIT compiler can take advantage of it."
http://code.google.com/p/unladen-swallow/wiki/Release2009Q3

Ça évite d'avoir juste des "???" dans gdb ;-)

La modif a été faite directement dans LLVM :
http://llvm.org/docs/DebuggingJITedCode.html

Je viens de voir Le Petit Nicolas au cinéma et je l'ai adoré :-) Le film est très drôle et divertissement.

Il existe le projet GGCC (qui existe depuis... 2007 ?) qui rajoute des extensions à GCC :
http://www.ggcc.info/
http://2008.rmll.info/Projet-GGCC-Global-GCC.html

GGCC utilise par exemple du LISP et du Prolog pour les vérifications, et se branche sur GCC avec ICI :
http://ctuning.org/wiki/index.php/CTools:ICI

« The Interactive Compilation Interface (or 'ICI' for short) is a plugin system with a high-level compiler-independent and low-level compiler-dependent API to transform current compilers into collaborative open modular interactive toolsets. The ICI framework acts as a "middleware" interface between the compiler and the user-definable plugins. »

Et au sujet des plugins, il y a cette page qui explique un peu plus de choses :
http://gcc.gnu.org/wiki/GCC_Plugins

s'engager au freeze, la garanti de non-evolution...

Il ne s'agit que de figer le langage, la bibliothèque standard va continuer à évoluer, comme indiqué dans la dépêche.

je pense que la synthaxe reste perfectible

Les ajouts récents (with, décorateur de classe, etc.) sont du sucre syntaxique, càd qu'on peut s'en passer. Je pense que le noyau dur du langage (définition d'une fonction/classe, les modules, les boucles, les exceptions, etc.) est stable et cohérent, et qu'on devrait y survivre durant quelques années. S'il y avait des énormités insupportables, ils ont été corrigés ou alors ce n'était pas si insupportable que ça :-)

si je ne balance pas ver 3.x de python (...) qu'on y perde en performance

Unladen Swallow et PyPy ont un compilateur à la volée (JIT) qui montre de gros gains de performances, c'est très prometteur. Si Python2 devient 5x plus rapide mais que Python3 reste 30% plus lent que Python2, je pense que les 30% deviendront négligeables (ou dumoins, acceptables).

Petit à petit, les nouvelles fonctions et optimisations arrivent plutôt dans Python3 que dans Python2.

Le problème est que seul CPython implémente complètement « Python » (le langage et la bibliothèque standard), c'est le standard de facto. Par contre, PyPy et Jython en sont à Python 2.5 et IronPython se prépare à Python 2.6. PyPy, Jython et IronPython n'ont sont même pas encore à Python 2.6 (sorti il y a un peu plus d'un an), que CPython court déjà vers Python 3.2 et bientôt 2.7...

En d'autres termes, passer de la version 2.x à 2.x+1 prend trop de temps qu'on ne peut même pas encore envisager la migration à Python 3.1 (manque de main d'œuvre).

Au sujet de la migration des projets utilisant Python 2.x et voulant migrer à Python 3.x, il y a un outil de migration (2to3) qui permet de corriger la syntaxe. Par contre, le problème est plus au niveau des bibliothèques (PyQt, Twisted, Django, ...) qui migrent doucement vers Python3.

PS : Unladen Swallow est un fork de la version 2.6.1, donc pareil, pas de Python3 pour cette implémentation pour le moment.

Bah c'est surtout que le dépôt non-free n'est pas actif de base. Il faut l'activer manuellement. La séparation permet d'avoir un OS libre si on le désire. Mais ça permet aussi d'avoir un OS presque libre si on a vraiment besoin de trucs propriétaires. Je trouve que c'est un bon compromis :-)

Si j'ai bien compris, ça faisait longtemps qu'OSS était émulé au dessus d'ALSA, mais l'émulation était faite dans le noyau. Or c'est quelque chose de compliqué, lourd et bogué. Et puis, personne ne voulait plus le maintenir. J'ai bon ?

Fedora veut également abandonner OSS. Je ne sais pas où ça en est.

Sur LWN, il y a un excellent article « The past, present, and future of Linux audio » également issu de Linux Plumbers (comme la dépêche de patrick_g). Cet article parle d'OSS, ALSA, JACK et PulseAudio (erk!) notamment, mais également de Windows et Mac OS X.
http://lwn.net/Articles/355542/
(je ne sais pas si l'article est déjà public, si non, achetez vous un abonnement, LWN est une excellente source d'information !)

Les microcodes sont "séparés du noyau Debian". Ok, mais ils seront toujours disponible dans Debian non ? Et d'ailleurs, ça contient quoi un microcode ? Est-il possible d'écrire un microcode libre pour remplacer un microcode propriétaire ? Ça a toujours été un truc nébuleux pour moi, je sais juste qu'il en faut pour certains pilotes wifi (par exemple) :-)

Tiens d'ailleurs, il semble que Lantronix commence tout juste à utiliser Linux (justement avec l'XPort Pro ?). Avant ils avaient leur OS propriétaire. Qu'en est-il des kits de développements ? Digi semble utiliser Eclipse et Linux.

Pourquoi acheter un nouvel ordinateur si tu as déjà un ordinateur chez toi ? Il est trivial d'installer Apache (ou autre) sur un « poste de travail » Linux. Sinon, y'a des trucs plus rigolos comme :
https://addons.mozilla.org/en-US/firefox/addon/3002

En attendant je suggère aux modérateurs de te mettre en tête sur la liste des dépêches à primer, ce sera toujours ça.

Je vais te livrer un secret : la note d'une dépêche entre en jeu dans le choix des dépêches à primer. As-tu cliqué sur "pertinent" ?

Cette dépêche est issue en parti de l'article "X.Org releases: present and future" écrit par Nathan Willis et publié sur l'excellent site LWN :
http://lwn.net/Articles/355821/

Comment tu fais quand ils ont quitté la boite ? :-)

Plus la quantité de mémoire augmente, plus le taux d'erreur augmente. Andi Kleen et Fengguang Wu ont écrit un patch "HWPOISON" qui permet de rattraper les erreurs "soft" et "hard" de la mémoire.
http://lwn.net/Articles/348886/

Cet article est fort intéressant. Mais si j'ai bien compris, il faut le processeur associé, genre un Xeon Nehalem-EX et son architecture Machine Check Abort (MCA).

Hélas j'ai travaillé tout seul donc il manque l'aspect collaboratif

Il existe le Git Community Book :
http://book.git-scm.com/

Je l'ai imprimé en version PDF et il est très bien :
* bonne introduction avec le « système de fichiers git » (la manière dont sont stockées les données)
* difficulté progressive
* jolis schémas qui expliquent bien
* présente de très nombreuses fonctionnalités

« Linuxfr était autrefois un repaire de passionnés de technique »

liberforce qui a écrit un journal n'est-il pas un passionné de la technique ? Et moi alors ?

S'il n'y a pas de commentaire, je crois plutôt que c'est parce que SystemTap est un projet encore jeune (stable depuis qq. jours seulement), et rarement installé (il semble que seul Fedora inclut tout ce qu'il faut pour l'utiliser). Pourtant, le potentiel de SystemTap est énorme ! Je me souviens de libristes tristes de ne pas avoir DTrace sous Linux, or on l'a maintenant :-) Il n'y a plus qu'à en faire la pub (écrire des articles pour expliquer comment l'installer / l'utiliser) pour le propagner.

Au sujet de Valgrind, je l'utilise régulièrement et il fonctionne à merveille. En même temps, vu que tout fonctionne du premier coup, je ne pense même pas à en parler :-) Souvent, ce n'est que lorsqu'on a des problèmes avec un logiciel qu'on en parle. J'ai appris récemment que j'avais des utilisateurs de mon projet lorsque le serveur qui l'hébergeait était hors-service !

Btrfs a été introduit dans Linux 2.6.29 qui est sorti le 24 mars 2009. http://linuxfr.org/2009/03/24/25162.html

Par contre, le format "on disk" a encore changé récemment (pour Linux 2.6.31, pour améliorer les performances, certes) :
http://linuxfr.org/2009/09/10/25848.html#btrfs

Extrait du wiki de btrfs : « Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review. The Btrfs disk format is not yet finalized, but it will only be changed if a critical bug is found and no workarounds are possible. »
http://btrfs.wiki.kernel.org/index.php/Main_Page

Libre à vous de tester, ou pas :-)

Je ne sais pas dans quel monde vous vivez. Madame Michu utilise hotmail, gmail, laposte, ... : un webmail en ligne.

Sinon pour ne pas perdre de fichier lorsqu'un "rollback" est fait par apt-get, il « suffit » que le système et la $HOME soient sur des partitions séparées.

SSTIC coûte 230 EUR (60 EUR pour les étudiants).

PacSec (Japon) :

Register by October 10: C$1200 / ~99,750円
Register by November 3: C$1400 / ~126,000円
Register at the event: C$1850 / ~168,000円

The price will be charged in Canadian dollars(CDN).

Black Hat USA (Las Vegas) :

Pricing for 2009 (depending on the date of registration):
Early: $1395 ends Jun 1
Regular: $1595 ends Jul 1
Late: $1795 ends Jul 22
Onsite: $2095
Training: 1700 - 3900 USD per session

Il existe encore un paquet d'autres conférences. Je me demande si DefCon n'est pas gratuit ?

Pour suivre les correctifs de la faille, voir le CVE qui lui a été assigné :
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3234

Il semble que la faille ait été corrigé le 15 septembre dans le dépôt git :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)

display_errors = off [1]

Par contre, en cours développement, il FAUT afficher TOUS les avertissements (et le corriger bien sûr ;-)).

register_globals = off
allow_url_fopen = off

C'est encore activé par défaut ces horreurs ?

désactiver certaines fonctions si on en a pas besoin

Ce modèle de sécurité (liste noire) est bancal à mon avis. Plutôt que de lister quelques fonctions dangeureuses, il vaut mieux dresser une liste exhaustive des fonctions dont on a besoin (liste blanche). Je ne sais pas si c'est possible en PHP, mais ça serait la meilleure solution.

Pour illustrer mon propros (liste blanche vs liste noire) : c'est comme les protections « anti-include ». Refuser le motif « ../ » dans un nom de fichier est insuffisant. Si l'attaquant arrive à obtenir le chemin absolu (facile en général), il pourra accéder à n'importe quel fichier. La bonne solution est d'utiliser real_path() et vérifier que le fichier (ou le chemin) est dans une liste blanche.

modifier les applis pour ne permettre qu'un certain nombre de tentatives de login par minutes (à la fail2ban)

Moui. Enfin, il faut aussi remonter les alertes au webmestre. Il existe par exemple http://php-ids.org/

éventuellement utiliser le safemode pour mysql, mais normalement pas de soucis de ce coté si le reste est ok

Je pense qu'il vaudrait mieux créer un utilisateur MySQL aux droits restreints (ex : LOAD_FILE / SELECT INTO / ... sont-ils vraiment utiles sur un site web ?).

--

De ma petite expérience, PHP souffre de plusieurs problèmes :

* Le langage est trop laxiste, PHP devrait obliger les développeurs à corriger les erreurs. D'ailleurs, il faut beaucoup de motivation pour activer tous les avertissements et tous les corriger. Je vous déconseille de le faire sur un gros projet existant sous peine de dépression :-)

* Sites web développés par des développeurs ayant appris la programmation sur le tas (comme tout le monde) et n'ayant aucune connaissance en sécurité (comme la grande majorité des développeurs). Dans le cas de PHP, ça importe car les applications (sites web) sont accessibles depuis Internet.

* PHP et MySQL sont souvent installés avec un maximum de fonctionnalités, alors que du point de vue sécurité, il faudrait l'inverse. Exemple : allow_url_fopen activé par défaut.

* Pas de politique de sécurité globale : une faille PHP permet d'accéder à la base de données, au FTP, (parfois) aux autres sites hébergés sur le même serveur, puis à la boîte mail, etc. Un des problèmes courant est que le mot de passe est le même partout (FTP, MySQL, mail, etc.).

--

Je ne suis pas sûr que PHP soit l'origine du mal. C'est plutôt que les développeurs web débutent avec PHP. Il y a une association PHP = programmeur débutant, et donc indirectement PHP = site web peu sûr, puis PHP = langage peu sûr.

PS : Bien sûr, le langage en lui-même est vraiment une grosse merde comparés à ses concurrents (notamment Python et Ruby).

« Pas sûr que mettre magic_quotes_gpc à on soit une bonne solution »

C'est surtout une grosse blague qui n'empêche sûrement pas les injections SQL (on peut injecter du SQL sans apostrophe ou guillemet si la requête SQL est mal écrite), mais emmerde surtout les développeurs.

PHP a enfin décidé de supprimer cette vieille blague (magic_quotes) dans PHP6. Voir la décision et les raisons :
http://www.php.net/~derick/meeting-notes.html#magic-quotes

Quelques lignes plus bas, on lit que le safe_mode sera également supprimé de PHP.