GNU/Linux Magazine 122

Fidèles à nos habitudes, nous décortiquons la toute dernière version du noyau, cette fois-ci étiquetée 2.6.32. Elle a une importance toute particulière pour deux raisons. D'une part, elle fait suite à une version 2.6.31 jugée légèrement décevante car apportant de nombreux bugs et régressions. D'autre part, il ressort des discussions ayant eu lieu à la Linux Plumbers Conference le 23 septembre que ce noyau 2.6.32 sera probablement utilisé par les prochaines versions de plusieurs distributions ayant un support à long terme, notamment Debian Squeeze et Ubuntu 10.04. Rentrons à présent dans le vif du sujet, en vous souhaitant une bonne lecture pour ce long Kernel Corner.

Pour rendre des pages web plus dynamiques, il est fréquent d'avoir recours au javascript pour gérer des actions réalisées par l'utilisateur : passage de la souris au-dessus d'une image, clic, etc. Dans le cadre d'une application web, on peut supposer que toute personne souhaitant utiliser le logiciel activera javascript... On ne peut pas gérer un site web de la même façon !

Qu'il s'agisse de dépister des anomalies dans un code que l'on veut robuste ou de démontrer qu'un prestataire n'a pas respecté l'état de l'art, ou plus simplement pour améliorer la qualité de son projet, il arrive un moment où l'on souhaite faire le point sur la qualité technique globale de son projet. Ce genre de travail nécessite bien évidemment une bonne maîtrise de la technologie utilisée, mais aussi un outillage assez élaboré pour analyser et remonter les potentiels problèmes. S'il existe de nombreuses solutions open source – PMD, Cloc, Findbugs... – pour analyser un projet et remonter ses indicateurs, il reste fastidieux de mettre en place tous ces outils et surtout encore plus laborieux de faire la synthèse des différents résultats obtenus.