Ce pilote évoque petit à petit au fil des versions du noyau Linux. Le pilote quitte d'ailleurs le dossier "staging" pour entrer dans le noyau officiel dans la version 3.3 (en cours de développement). The GMA500 graphics driver for Intel's US15W and some Hyper V drivers have matured in the staging area and were moved to the subsystems responsible for these kind of drivers. http://www.h-online.com/open/features/Kernel-Log-Linux-3-3-goes-into-testing-1418516.html
Il y a quelques mois était publiée la version 5.3.7 de PHP, sans s'assurer que certains bugs critiques, comme celui de la fonction crypt(), avaient été corrigés.
Euh non, il n'y avait pas de bug. La fonction a été modifié suite à un avertissement d'un outil d'analyse statique, modification faite par l'auteur du langage et censé améliorer la sécurité. Plus d'info sur cette vulnérabilité : https://plus.google.com/111631720833482085895/posts/G3pKmqn4VFZ
Ce n'est pas Stefan Esser qui a trouvé la faille 20 jours après PHP 5.3.9, mais masugata qui a rapporté le bug 1 jour après PHP 5.3.9. Par contre, sûrement que quand Stefan rapporte un bug, il fait plus de bruit et donc les développeurs sont plus pressés de corriger le bug.
Contribuant à Python, je suis étonné des méthodes de travail des développeurs PHP. Ils n'écrivent pas ou peu de test, et à l'époque de PHP 5.3.7, il y avait 200 tests qui ne passaient pas, et pourtant ils ont publié une nouvelle version. Pour le correction pour le DoS (hash), je doute qu'un test ait été écrit vu que le correctif ne corrigeait pas la faille (dumoins, pas tous les cas). Pour le correctif du correctif, je ne vois pas non plus de test de non-régression. Là il y a 82 tests qui ne passent pas sur PHP 5.3, 86 tests sur PHP 5.4, et 104 sur HEAD. C'est beaucoup mieux !
À côté de ça, ça plusieurs semaines qu'un débat enflammé a lieu sur la liste de diffusion et le bug tracker Python pour choisir le meilleur correctif pour le même bug (DoS sur la table de hash). Je me dis que ce débat n'est pas si inutile : relire un patch à plusieurs permet d'avoir un meilleur code, même si la moindre modification prend plus de temps.
Python est blindé niveau tests et gare à celui qui pête un des 70 buildbots ! Pour Python 3.3, la majorité des buildbots sont verts, mis à part bugs connus et rapportés, pour les autres versions, buildbot est plus instable.
Ma femme travaille dans une crèche. Elle m'a dit que les enfants qui ont des couches lavables ont plus de problèmes aux fesses, plus d'irritations. Vu qu'elle voit 50 bébés différents et que c'est son métier, je lui fais confiance.
Cela concerne l'ensemble de la suite logicielle NuFirewall distribuée sous licence GPL, à l'exception de la brique propriétaire du client Windows qui n'est donc pas disponible sur le site.
Espérons que le repreneur d'EdenWall, Netasq, va libérer le code de l'agent Windows.
Le code de l'agent Windows est clairement propriétaire. C'était une manière pour INL/EdenWall de garder le monopole sur le logiciel qu'elle éditait (son fer de lance qui la démarquait de la concurrence), le parefeu NuFW.
Il existe 3 agents libres pour Linux, FreeBSD et Mac OS X : agent en mode texte, agent graphique (C++ et Qt, le "QNU", je n'ai pas vérifié s'il est disponible sur ufwi.org) et agent "transparent" (plugin PAM lancé en arrière plan).
Le protocole réseau de NuFW est public, le plus difficile est de trouver des informations sur la table des connexions sous Windows (peu voir non documenté). L'agent Windows utilise notamment un pilote Windows pour récupérer ces informations. Si un ancien client d'EdenWall souhaite faire évoluer l'agent (ou en écrire une nouvelle implémentation), l'agent 64 bits ne supportant pas le VPN par exemple (ce qui commence à poser problème aujourd'hui), il lui suffit d'utiliser la rétro ingénierie.
Bien que ça ne soit pas facile à faire dans une société avec un grand parc existant, la solution évidente à ce problème est de passer les postes sous Linux (ou FreeBSD). La migration pouvant être progressive (règles différentes pour le parc Windows et pour le parc Linux, en utilisant des règles non authentifiés pour Windows par exemple).
Un projet d'agent Windows alternatif utilisant Active Directory pour "identifier" l'origine des connexions avait été évoqué pendant un temps (sécurité plus faible mais meilleure qu'un parefeu non authentifiant), mais le projet ne s'est jamais concrétisé. Je ne connais pas assez Active Directory pour savoir quelles informations il fournit.
Enfin, il existe un autre type d'authentification (faible) : un agent implémenté en Java cette fois-ci, l'applet Java, qui répond simplement "Hello" chaque fois qu'on l'interroge. Cet agent utilise un tunnel chiffré pour son lien avec nuauth (comme les autres agents) et exige une authentification initiale (identifiant et mot de passe de l'utilisateur), mais est incapable de certifier qu'une nouvelle connexion a été ouverte par le poste client sur lequel il tourne.
L'applet Java ne semble pas non être disponible sur ufwi.org. Si une personne en possède une copie, ou mieux, une copie des sources, je pense que la FSF serait intéressée :-)
Euh, c'est peut-être volontaire car j'ai entendu qu'ICC est juste le compilateur C le plus rapide qui existe actuellement (mais c'est un compilateur proprio).
Y'a aussi une astuce toute bête qui m'a fait gagner beaucoup de temps : vim fichier +ligne ouvre un fichier en se positionnant directement à la ligne spécifiée.
J'ai également jeté un coup d'oeil rapide. Bah... je ne vois pas où est le secret industriel qui a motivé Free à violer la licence GPL alors qu'ils en étaient pleinement conscient.
J'ai vu quelques patchs pour permettre la cross-compilation, d'autres pour ajouter des pilotes variés au noyau, et divers petits détails (genre afficher le nom d'hôte complet). Au niveau des trucs spécifique, j'ai vu quelques morceaux qui concernent 6to4rd (tunnel IPv6 dans IPv4 à la mode Free), mais il me semble que ce protocole est public et bien documenté. En tout cas, je n'ai pas vu de truc révolutionnaire, mais comme j'ai jeté un coup d'oeil rapide, je suis peut-être passé à côté ?
De toute manière, je pense que le plus important (niveau valeur ajoutée) sont les logiciels métiers développés en interne.
Comme indiqué dans un autre commentaire, les utilisateurs n'ont pas idée du temps que prend un développement. Je vois par exemple une demande "Montrer les photos géolocalisées sur une carte" pour 5€ (logiciel Shotwell). Bon. Disons qu'un développeur gagne 1500€ net/mois (environ 24 k€ brut / an, c'est plutôt mal payé). Disons qu'en plus il bosse 40h/semaine le pauvre, ça donne environ 9,38€ de l'heure. Bah pour 5€, il peut bosser environ 30 minutes.
Peut-être qu'il y a des développeurs capables d'entrer dans un projet de la taille de Shotwell en 10 minutes, coder la fonction en 10 minutes et trouver un fond de carte les 10 minutes restantes. Perso, je met plutôt 1 jour à 1 semaine pour entrer dans un projet, et pour la fonctionnalité, je pense qu'il faut bien 1 à 2 semaines de développement (estimation certifiée pifomètre). Pour le fond de carte : je suppose qu'il en faut plusieurs. Je doute qu'une planisphère convienne à un français par exemple (toutes les photos feraient un énorme tas). J'estime qu'il faut au strict minimum 10 jours de travail, et par expérience, je multiple arbitrairement par deux : donc 20 jours. 20 jours, ça donne un salaire => 1500€.
5€ ça fait donc 0,3% du coût que j'ai estimé. Je pense qu'il est vital que des développeurs indiquent leur estimation de la charge de travail (en "jours-homme" par exemple). Quitte à indiquer plusieurs estimations, ou calculer une moyenne des estimations. Il faudrait peut-être redécouper une fonction en plusieurs étapes, et peut-être permettre de financer chaque étape.
Quand je vois "Reconnaissance faciale dans le gestionnaire de connexion" pour 0€ ça me fait doucement rigoler. Je ne vois pas l'intérêt de faire une liste des rêves des utilisateurs. Vous pouvez voter autant que vous voulez, ça ne motivera pas un développeur à s'y mettre (en tout cas, perso je n'en tiens pas compte).
Bien sûr, le site permet à plusieurs personnes de financer une demande de fonction, mais sans indicateur, ça laisse penser au "client" qu'il aura sa fonction pour 5€. J'attend qu'il y a une demande à 100€ pour considérer sérieusement ce site.
Si tu prends l'exemple de la dépêche, il faut modifier quatre pointeurs atomiquement. Or la majorité des instructions modifient un seul mot mémoire à la fois.
// Insère atomiquenent un nœud dans une liste doublement liée
atomic {
newNode→prev = node;
newNode→next = node→next;
node→next→prev = newNode;
node→next = newNode;
}
L'agent EdenWall est protégé par WinLicense. C'est un logiciel de protection propriétaire anti-ingénierie inverse qui semble assez poussé au point qu'il soit utilisé par certains malwares. Du coup, il faut expliquer à l'éditeur d'anti-virus qu'un binaire protégé WinLicense n'est pas forcément un malware...
Les navigateurs essaient par tous les moyens possibles de rendre cette frontière la plus étanche possible, mais on imagine facilement qu'avec des nouvelles fonctionnalités ajoutées à JavaScript, de nouvelles failles peuvent facilement voir le jour.
Je ne pense pas que le fait d'être passé par des investisseurs soit la principale raison de la "chute" d'EdenWall.
Je pense plutôt que c'est le fait que la société se soit concentrée uniquement sur un seul produit, son appliance réseau (qui est essentiellement un parefeu), en utilisant NuFW comme fer de lance. Il y a beaucoup de concurrence dans le domaine des parefeux : Netasq et Arkoon en France, Cisco, Juniper, Fortinet, Palo Alto, ... à l'international. Quand un parefeu tombe en panne, le coût pour une entreprise est énorme. Alors remplacer un parefeu fonctionnel par un nouveau parefeu d'une jeune société méconnue (comparée à Cisco ou Juniper par exemple), il faut oser sauter le pas. Pour NuFW : la nécessité d'avoir un agent sur chaque poste client semble trop contraignant pour choisir NuFW plutôt qu'un portail captif, filtrage par adresse MAC, la norme 802.1x ou autre. Quand on contrôle son parc ça passe, mais souvent il y a des ordinateurs portables qui s'ajoutent, puis les terminaux mobiles (smartphones), etc. Autrement dit, bien que NuFW soit un bon parefeu, je doute qu'il réponde à vrai besoin. Les solutions concurrentes sont un compromis sécurité/facilité (de déploiement/administration) suffisant.
Au sujet de l'activité de service : la qualité des services vendus par EdenWall fidélisait les clients. Plusieurs fois, ça a donné confiance aux clients qui osaient alors sauter le pas en achetant une appliance. Alors que chercher des clients en attaquant directement par la vente d'appliance est autrement plus difficile.
Enfin, c'est mon analyse personnelle. Il y a d'autres facteurs, cités dans le journal, et peut-être aussi quelques soucis organisationnels (enfin, ça je pense pas que ça soit une exclusivité EdenWall ;-)).
We currently refuse to touch the ASPM registers if the BIOS tells us that
ASPM isn't supported. This can cause problems if the BIOS has (for any
reason) enabled ASPM on some devices anyway. Change the code such that we
explicitly clear ASPM if the FADT indicates that ASPM isn't supported,
and make sure we tidy up appropriately on device removal in order to deal
with the hotplug case. If ASPM is disabled because the BIOS doesn't hand
over control then we won't touch the registers.
Donc effectivement, ce n'est pas un bug noyau, mais -encore une fois- un bug du BIOS. Le bon correctif pour ton PC portable consistera donc à patcher ton BIOS.
C'est quoi ça, de la modification rétroactive du passé ? Mauvaise idée, ne pas utiliser.
Je dirai que ce n'est une mauvaise idée que pour les commits déjà public. Pour les commits locaux, on peut en faire ce qu'on veut : les fusionner, les diviser, les réorganiser, les éditer, etc. Je fais ça à peu prêt quotidiennement : je profite de la vitesse de Git/Mercurial pour faire des micro-commits, puis je nettoie avant de pousser. D'ailleurs, Mercurial est assez lent pour ce genre d'opération (greffon histedit), alors que c'est super facile et efficace avec git rebase -i.
[^] # Re: Poulsbo ou Poulspabo
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Quatre actualités concernant la pile graphique de Linux. Évalué à 4.
Depuis que j'ai écrit mon article fin 2009, ça a pas mal bougé avec le gros travail d'Alan Cox sur le pilote gma500.
https://linuxfr.org/news/intel-ne-maintient-plus-le-pilote-linux-poulsbo-depuis-un-an-et
Ce pilote évoque petit à petit au fil des versions du noyau Linux. Le pilote quitte d'ailleurs le dossier "staging" pour entrer dans le noyau officiel dans la version 3.3 (en cours de développement).
The GMA500 graphics driver for Intel's US15W and some Hyper V drivers have matured in the staging area and were moved to the subsystems responsible for these kind of drivers.
http://www.h-online.com/open/features/Kernel-Log-Linux-3-3-goes-into-testing-1418516.html
# Détails sur les 2 dernières vulnérabilités PHP, méthodes de développement
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche État d'insécurité chez PHP. Évalué à 10.
Il y a quelques mois était publiée la version 5.3.7 de PHP, sans s'assurer que certains bugs critiques, comme celui de la fonction crypt(), avaient été corrigés.
Euh non, il n'y avait pas de bug. La fonction a été modifié suite à un avertissement d'un outil d'analyse statique, modification faite par l'auteur du langage et censé améliorer la sécurité. Plus d'info sur cette vulnérabilité :
https://plus.google.com/111631720833482085895/posts/G3pKmqn4VFZ
Au sujet de la faille introduite par un correctif de l'attaque par déni de service de la table de hachage (PHP 5.3.9), j'ai également écrit sur un bref article :
https://plus.google.com/111631720833482085895/posts/dJ7RyRSj31f
Ce n'est pas Stefan Esser qui a trouvé la faille 20 jours après PHP 5.3.9, mais masugata qui a rapporté le bug 1 jour après PHP 5.3.9. Par contre, sûrement que quand Stefan rapporte un bug, il fait plus de bruit et donc les développeurs sont plus pressés de corriger le bug.
Contribuant à Python, je suis étonné des méthodes de travail des développeurs PHP. Ils n'écrivent pas ou peu de test, et à l'époque de PHP 5.3.7, il y avait 200 tests qui ne passaient pas, et pourtant ils ont publié une nouvelle version. Pour le correction pour le DoS (hash), je doute qu'un test ait été écrit vu que le correctif ne corrigeait pas la faille (dumoins, pas tous les cas). Pour le correctif du correctif, je ne vois pas non plus de test de non-régression. Là il y a 82 tests qui ne passent pas sur PHP 5.3, 86 tests sur PHP 5.4, et 104 sur HEAD. C'est beaucoup mieux !
À côté de ça, ça plusieurs semaines qu'un débat enflammé a lieu sur la liste de diffusion et le bug tracker Python pour choisir le meilleur correctif pour le même bug (DoS sur la table de hash). Je me dis que ce débat n'est pas si inutile : relire un patch à plusieurs permet d'avoir un meilleur code, même si la moindre modification prend plus de temps.
Python est blindé niveau tests et gare à celui qui pête un des 70 buildbots ! Pour Python 3.3, la majorité des buildbots sont verts, mis à part bugs connus et rapportés, pour les autres versions, buildbot est plus instable.
# Avis d'une éducatrice de jeunes enfants
Posté par Victor STINNER (site web personnel) . En réponse au journal Où on parle de couches.... Évalué à 5.
Ma femme travaille dans une crèche. Elle m'a dit que les enfants qui ont des couches lavables ont plus de problèmes aux fesses, plus d'irritations. Vu qu'elle voit 50 bébés différents et que c'est son métier, je lui fais confiance.
[^] # Re: Intéressé
Posté par Victor STINNER (site web personnel) . En réponse au journal Sprint CPython en ligne ce week-end (17/18 déc.). Évalué à 2.
je voulais à une époque mettre à jour la documentation
Tu veux dire que la documentation n'est pas complète ou désuette ? Bien sûr que c'est un bon sujet pour le sprint.
[^] # Re: un peu de jugeote...
Posté par Victor STINNER (site web personnel) . En réponse au journal Vers le brevetage du vivant ?. Évalué à 5.
J'aurais d'ailleurs tendance à le croire pour l'hoax sur l'inde tant les chiffres avancées paraissent terrifiants et dépourvus de sources.
L'article "Suicide collectif de 1500 fermiers indiens ruinés à cause des OGM" ne cite pas clairement ses sources, mais on peut les retrouver. L'article se termine par "Source: les mots ont un sens" (article qui date d'avril 2009) et contient une vidéo qui est un extrait de l'émission "L'effet Papillon" de Canal+. La vidéo semble avoir été mise en ligne par "pourunmondedurable.blogspot.com".
http://www.lesmotsontunsens.com/inde-suicide-collectif-1-500-paysans-ogm-coton-bt-monsanto-4131
http://pourunmondedurable.blogspot.com/
Le titre de l'article lesmotsontunsens.com a été changé hier (sûrement à cause de la rediffusion via Wikistrike) :
Cet article ne cite pas explicitement ses sources, juste "Selon les ONG".
Voir aussi un autre article plus récent du site "les mots ont un sens" :
http://www.lesmotsontunsens.com/inde-coton-bt-ogm-resistance-maladie-7281
# Historique du code source et de la société INL/EdenWall
Posté par Victor STINNER (site web personnel) . En réponse au journal Nouvel hébergement du projet NuFW sur ufwi.org. Évalué à 3.
Historique de 2003 à 2011 :
http://www.haypocalc.com/blog/index.php/2011/12/05/244-fsf-france-met-en-ligne-code-source-edenwall
[^] # Re: NuAgent pas disponible ?
Posté par Victor STINNER (site web personnel) . En réponse au journal Nouvel hébergement du projet NuFW sur ufwi.org. Évalué à 4.
Extrait du communiqué de presse de FSF France :
Espérons que le repreneur d'EdenWall, Netasq, va libérer le code de l'agent Windows.
Le code de l'agent Windows est clairement propriétaire. C'était une manière pour INL/EdenWall de garder le monopole sur le logiciel qu'elle éditait (son fer de lance qui la démarquait de la concurrence), le parefeu NuFW.
Il existe 3 agents libres pour Linux, FreeBSD et Mac OS X : agent en mode texte, agent graphique (C++ et Qt, le "QNU", je n'ai pas vérifié s'il est disponible sur ufwi.org) et agent "transparent" (plugin PAM lancé en arrière plan).
Le protocole réseau de NuFW est public, le plus difficile est de trouver des informations sur la table des connexions sous Windows (peu voir non documenté). L'agent Windows utilise notamment un pilote Windows pour récupérer ces informations. Si un ancien client d'EdenWall souhaite faire évoluer l'agent (ou en écrire une nouvelle implémentation), l'agent 64 bits ne supportant pas le VPN par exemple (ce qui commence à poser problème aujourd'hui), il lui suffit d'utiliser la rétro ingénierie.
Bien que ça ne soit pas facile à faire dans une société avec un grand parc existant, la solution évidente à ce problème est de passer les postes sous Linux (ou FreeBSD). La migration pouvant être progressive (règles différentes pour le parc Windows et pour le parc Linux, en utilisant des règles non authentifiés pour Windows par exemple).
Un projet d'agent Windows alternatif utilisant Active Directory pour "identifier" l'origine des connexions avait été évoqué pendant un temps (sécurité plus faible mais meilleure qu'un parefeu non authentifiant), mais le projet ne s'est jamais concrétisé. Je ne connais pas assez Active Directory pour savoir quelles informations il fournit.
Enfin, il existe un autre type d'authentification (faible) : un agent implémenté en Java cette fois-ci, l'applet Java, qui répond simplement "Hello" chaque fois qu'on l'interroge. Cet agent utilise un tunnel chiffré pour son lien avec nuauth (comme les autres agents) et exige une authentification initiale (identifiant et mot de passe de l'utilisateur), mais est incapable de certifier qu'une nouvelle connexion a été ouverte par le poste client sur lequel il tourne.
L'applet Java ne semble pas non être disponible sur ufwi.org. Si une personne en possède une copie, ou mieux, une copie des sources, je pense que la FSF serait intéressée :-)
[^] # Re: et là distrib qui va avec ?
Posté par Victor STINNER (site web personnel) . En réponse au journal Nouvel hébergement du projet NuFW sur ufwi.org. Évalué à 10.
La version Qt de l'agent NuFW aurait du s'appeller QNU mais ça a été refusé par le responsable marketing.
[^] # Re: Benchmark
Posté par Victor STINNER (site web personnel) . En réponse au journal Sortie du compilateur libre Open64 en version 5.0. Évalué à 4.
Oups, je croyais que c'était un benchmark réalisé par les auteurs d'Open64 (ou AMD). En fait non, c'est un site qui est -je crois- indépendant.
[^] # Re: Benchmark
Posté par Victor STINNER (site web personnel) . En réponse au journal Sortie du compilateur libre Open64 en version 5.0. Évalué à 2.
Dommage qu'il n'y est pas ICC dans le comparatif.
Euh, c'est peut-être volontaire car j'ai entendu qu'ICC est juste le compilateur C le plus rapide qui existe actuellement (mais c'est un compilateur proprio).
[^] # Re: Compilateur?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sun^WOracle Solaris 11. Évalué à 3.
"pkg install header-math" par exemple
[^] # Re: En vrac, mes préférés
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Vim fête son 20e anniversaire. Évalué à 3.
Y'a aussi une astuce toute bête qui m'a fait gagner beaucoup de temps : vim fichier +ligne ouvre un fichier en se positionnant directement à la ligne spécifiée.
# IPv6 ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Historique des serveurs LinuxFr.org. Évalué à 7.
Dans la dernière dépêche il était noté :
Qu'en est-il aujourd'hui ? Le datacenter où est le serveur ne gère pas IPv6 ?
[^] # Re: Contenu des patches
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Free publie enfin ses patchs sur les logiciels libres. Évalué à 5.
J'ai également jeté un coup d'oeil rapide. Bah... je ne vois pas où est le secret industriel qui a motivé Free à violer la licence GPL alors qu'ils en étaient pleinement conscient.
J'ai vu quelques patchs pour permettre la cross-compilation, d'autres pour ajouter des pilotes variés au noyau, et divers petits détails (genre afficher le nom d'hôte complet). Au niveau des trucs spécifique, j'ai vu quelques morceaux qui concernent 6to4rd (tunnel IPv6 dans IPv4 à la mode Free), mais il me semble que ce protocole est public et bien documenté. En tout cas, je n'ai pas vu de truc révolutionnaire, mais comme j'ai jeté un coup d'oeil rapide, je suis peut-être passé à côté ?
De toute manière, je pense que le plus important (niveau valeur ajoutée) sont les logiciels métiers développés en interne.
# Coût sous-estimé
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Lancement de la bêta d’Elveos. Évalué à 6.
Comme indiqué dans un autre commentaire, les utilisateurs n'ont pas idée du temps que prend un développement. Je vois par exemple une demande "Montrer les photos géolocalisées sur une carte" pour 5€ (logiciel Shotwell). Bon. Disons qu'un développeur gagne 1500€ net/mois (environ 24 k€ brut / an, c'est plutôt mal payé). Disons qu'en plus il bosse 40h/semaine le pauvre, ça donne environ 9,38€ de l'heure. Bah pour 5€, il peut bosser environ 30 minutes.
Peut-être qu'il y a des développeurs capables d'entrer dans un projet de la taille de Shotwell en 10 minutes, coder la fonction en 10 minutes et trouver un fond de carte les 10 minutes restantes. Perso, je met plutôt 1 jour à 1 semaine pour entrer dans un projet, et pour la fonctionnalité, je pense qu'il faut bien 1 à 2 semaines de développement (estimation certifiée pifomètre). Pour le fond de carte : je suppose qu'il en faut plusieurs. Je doute qu'une planisphère convienne à un français par exemple (toutes les photos feraient un énorme tas). J'estime qu'il faut au strict minimum 10 jours de travail, et par expérience, je multiple arbitrairement par deux : donc 20 jours. 20 jours, ça donne un salaire => 1500€.
5€ ça fait donc 0,3% du coût que j'ai estimé. Je pense qu'il est vital que des développeurs indiquent leur estimation de la charge de travail (en "jours-homme" par exemple). Quitte à indiquer plusieurs estimations, ou calculer une moyenne des estimations. Il faudrait peut-être redécouper une fonction en plusieurs étapes, et peut-être permettre de financer chaque étape.
Quand je vois "Reconnaissance faciale dans le gestionnaire de connexion" pour 0€ ça me fait doucement rigoler. Je ne vois pas l'intérêt de faire une liste des rêves des utilisateurs. Vous pouvez voter autant que vous voulez, ça ne motivera pas un développeur à s'y mettre (en tout cas, perso je n'en tiens pas compte).
Bien sûr, le site permet à plusieurs personnes de financer une demande de fonction, mais sans indicateur, ça laisse penser au "client" qu'il aura sa fonction pour 5€. J'attend qu'il y a une demande à 100€ pour considérer sérieusement ce site.
# PyPy et mémoire transactionnelle
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche IBM lance la mémoire transactionnelle dans le matériel. Évalué à 3.
Les développeurs de PyPy (surtout Armin Rigo) sont motivés pour utiliser de la mémoire transactionnelle :
http://morepypy.blogspot.com/2011/08/we-need-software-transactional-memory.html
http://morepypy.blogspot.com/2011/06/global-interpreter-lock-or-how-to-kill.html
http://mail.python.org/pipermail/python-dev/2011-August/113188.html
http://mail.python.org/pipermail/pypy-dev/2011-August/008153.html
[^] # Re: Instructions atomiques
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche IBM lance la mémoire transactionnelle dans le matériel. Évalué à 2.
Si tu prends l'exemple de la dépêche, il faut modifier quatre pointeurs atomiquement. Or la majorité des instructions modifient un seul mot mémoire à la fois.
[^] # Re: Analyse pertinente ?
Posté par Victor STINNER (site web personnel) . En réponse au journal EdenWall : la descente aux enfers. Évalué à 2.
L'agent EdenWall est protégé par WinLicense. C'est un logiciel de protection propriétaire anti-ingénierie inverse qui semble assez poussé au point qu'il soit utilisé par certains malwares. Du coup, il faut expliquer à l'éditeur d'anti-virus qu'un binaire protégé WinLicense n'est pas forcément un malware...
Ah, les joies du logiciel propriétaire...
# Content Security Policy
Posté par Victor STINNER (site web personnel) . En réponse au journal Et pourquoi pas un nouveau modèle de sécurité pour le web ?. Évalué à 4.
Les navigateurs essaient par tous les moyens possibles de rendre cette frontière la plus étanche possible, mais on imagine facilement qu'avec des nouvelles fonctionnalités ajoutées à JavaScript, de nouvelles failles peuvent facilement voir le jour.
Cette approche me semble intéressante :
https://developer.mozilla.org/en/Security/CSP/Using_Content_Security_Policy
Voir aussi (plus vieux, plus spécifique) :
https://developer.mozilla.org/En/HTTP_access_control
[^] # Re: Désinformation ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Fedora devient une grande fille. Évalué à 2.
Enfin, y a aucun lien vers le wiki avec la liste des fonctionnalités.
Je ne sais pas si ça a été ajouté par la suite, mais le premier lien est :
http://fedoraproject.org/wiki/Releases/16/FeatureList
« Releases/16/FeatureList »
[^] # Re: Le fond
Posté par Victor STINNER (site web personnel) . En réponse au journal EdenWall : la descente aux enfers. Évalué à 4.
L'ancienne version en PHP de NuFace (NuFace 2) est libre et disponible à l'adresse :
http://software.inl.fr/trac/wiki/EdenWall/NuFace
[^] # Re: Le fond
Posté par Victor STINNER (site web personnel) . En réponse au journal EdenWall : la descente aux enfers. Évalué à 4.
Voilà
https://github.com/haypo/nufw_mirror
[^] # Re: Analyse pertinente ?
Posté par Victor STINNER (site web personnel) . En réponse au journal EdenWall : la descente aux enfers. Évalué à 9.
Je ne pense pas que le fait d'être passé par des investisseurs soit la principale raison de la "chute" d'EdenWall.
Je pense plutôt que c'est le fait que la société se soit concentrée uniquement sur un seul produit, son appliance réseau (qui est essentiellement un parefeu), en utilisant NuFW comme fer de lance. Il y a beaucoup de concurrence dans le domaine des parefeux : Netasq et Arkoon en France, Cisco, Juniper, Fortinet, Palo Alto, ... à l'international. Quand un parefeu tombe en panne, le coût pour une entreprise est énorme. Alors remplacer un parefeu fonctionnel par un nouveau parefeu d'une jeune société méconnue (comparée à Cisco ou Juniper par exemple), il faut oser sauter le pas. Pour NuFW : la nécessité d'avoir un agent sur chaque poste client semble trop contraignant pour choisir NuFW plutôt qu'un portail captif, filtrage par adresse MAC, la norme 802.1x ou autre. Quand on contrôle son parc ça passe, mais souvent il y a des ordinateurs portables qui s'ajoutent, puis les terminaux mobiles (smartphones), etc. Autrement dit, bien que NuFW soit un bon parefeu, je doute qu'il réponde à vrai besoin. Les solutions concurrentes sont un compromis sécurité/facilité (de déploiement/administration) suffisant.
Au sujet de l'activité de service : la qualité des services vendus par EdenWall fidélisait les clients. Plusieurs fois, ça a donné confiance aux clients qui osaient alors sauter le pas en achetant une appliance. Alors que chercher des clients en attaquant directement par la vente d'appliance est autrement plus difficile.
Enfin, c'est mon analyse personnelle. Il y a d'autres facteurs, cités dans le journal, et peut-être aussi quelques soucis organisationnels (enfin, ça je pense pas que ça soit une exclusivité EdenWall ;-)).
# Le commit en question
Posté par Victor STINNER (site web personnel) . En réponse au journal La surconsommation électrique de Linux identifiée. Évalué à 10.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2f671e2dbff6eb5ef4e2600adbec550c13b8fe72
PCI: Disable ASPM if BIOS asks us to
author Matthew Garrett mjg@redhat.com
committer Jesse Barnes jbarnes@virtuousgeek.org
We currently refuse to touch the ASPM registers if the BIOS tells us that
ASPM isn't supported. This can cause problems if the BIOS has (for any
reason) enabled ASPM on some devices anyway. Change the code such that we
explicitly clear ASPM if the FADT indicates that ASPM isn't supported,
and make sure we tidy up appropriately on device removal in order to deal
with the hotplug case. If ASPM is disabled because the BIOS doesn't hand
over control then we won't touch the registers.
Donc effectivement, ce n'est pas un bug noyau, mais -encore une fois- un bug du BIOS. Le bon correctif pour ton PC portable consistera donc à patcher ton BIOS.
[^] # Re: Métadonnées
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Gitbuster II. Évalué à 10.
C'est quoi ça, de la modification rétroactive du passé ? Mauvaise idée, ne pas utiliser.
Je dirai que ce n'est une mauvaise idée que pour les commits déjà public. Pour les commits locaux, on peut en faire ce qu'on veut : les fusionner, les diviser, les réorganiser, les éditer, etc. Je fais ça à peu prêt quotidiennement : je profite de la vitesse de Git/Mercurial pour faire des micro-commits, puis je nettoie avant de pousser. D'ailleurs, Mercurial est assez lent pour ce genre d'opération (greffon histedit), alors que c'est super facile et efficace avec git rebase -i.