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.

Suite à l'article sur PNP4Nagios, PNP signifiant de façon récursive PNP is Not Perfparse, je me proposais d'écrire deux mots sur Perfparse. Pourquoi moi ? Pourquoi dire « je », alors que j'écris mes articles avec « nous » ? Tous simplement parce que j'ai eu l'opportunité de mener le développement de Perfparse de la version 0.08 à la 0.105.5 pendant quelques mois.

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.