Victor STINNER a écrit 1632 commentaires

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.

Pendant de longues années, mon site perso était hébergé sur en « mutualisé » chez OVH. Je n'avais qu'un accès FTP, protocole vieillot, qui passe mal les parefeux, lents, et surtout NON CHIFFRÉ ! Je viens de découvrir l'hébergeur AlwaysData qui propose un accès SSH, ce qui permet d'utiliser scp pour envoyer des fichiers, et offre donc un shell pour modifier directement les fichiers sur le serveur.

SSH est plus rapide et surtout beaucoup plus sûr (chiffré) que l'horrible FTP.

GCC 4.4.1 et 4.5 (snapshot du 27 août dernier) sont installables via MacPorts.

Fink permet d'installer GCC 4.4.1.

Je doute fortement qu'un client Mac lambda (celui qui a un iPod, iPhone et écoute en U2 en boucle) compile ses propres logiciels. On parle bien de développeurs là. Et il existe des développeurs capables d'installer GCC ;-)

Note : GCC 4.4.1 est la dernière version stable de GCC.

Hum, petit rappel : linuxfr est un site collaboratif. Comme tu sembles bien renseigné, n'hésite pas à proposer une dépêche pour les prochaines versions.

Il y a eu deux versions de cette dépêche. J'ai refusé la première parce qu'elle était trop maigre. Je trouve que le deuxième version était encore trop maigre, mais elle a quand même été approuvée :-) C'est génial quand on a plusieurs dépêches / journaux qu'on peut recouper pour en faire une dépêche plus complète. Mais quand on reçoit juste une dépêche maigre, on hésite entre ne rien publier (dommage) ou publier quand même.

Pour proposer une dépêche :
http://linuxfr.org/submit.html

PS : En plus, on peut gagner des livres, abonnements à des magazines, etc. J'ai reçu mon livre Ruby, yahoo !

L'auteur de grsecurity (suites de patchs pour le noyau visant à en reforcer la sécurité), Brad Spengler, a pris un malin plaisir à démontrer que SELinux (le concurrent de grsecurity) était faillible (contient une faille qui permettait de contourner les protections). Il a fait de même pour les autres systèmes de sécurité (LSM et audit en général). Voir les articles suivants pour les détails :
http://linuxfr.org/2009/07/18/25744.html
http://linuxfr.org/2009/07/24/25761.html
http://linuxfr.org/~patrick_g/28661.html

C'est grâce à au travail de Brad que la sécurité de SELinux a été renforcée dans Linux 2.6.31.

Au sujet de mmap_min_addr, je pense que cet article explique bien l'histoire.

Perso j'ai passé des heures à regarder defrag.exe. Mais je préférai son ancêtre sous MS-Dos, l'outil Norton dont j'ai oublié le nom, qui utilisait des couleurs plus jolies et il n'était pas nécessaire de scroller pour voir les animations :-) En plus, y'avait la douce musique du disque dur qui grattait. Ah quand je vais raconter ça à mes enfants qui auront des disques SSD avec défragmentation en ligne...

MiB : yep, d'extraterrestres, de flashouilleurs et de Will Smith.

Nan je déconne, MiB c'est Mailinblack !

Rah mince, la syntaxe (a href=...) ne fonctionne pas dans un commentaire ?

* The Big Kernel Lock lives on: http://lwn.net/Articles/86859/
* tty: BKL pushdown: http://lwn.net/Articles/268721/
* The big kernel lock strikes again: http://lwn.net/Articles/281938/
* "kill the Big Kernel Lock (BKL)" tree: http://lwn.net/Articles/282319/
* Removing the Big Kernel Lock: http://kerneltrap.org/Linux/Removing_the_Big_Kernel_Lock
* Kill BKL Vol. 2: http://lwn.net/Articles/283066/

Raah, je lis sans arrêt "Kill Bill".