Secu & Hack

p. 06 Jouons avec les Linux Pluggable Authentication Modules
p. 20 Kubernetes : comment éviter une catastrophe involontaire ?

Scripting Zone

p. 36 Développez un plug-in pour sudo pour mieux contrôler son utilisation et implémenter (simplement) vos idées originales !

Système & Bas Niveau

p. 50 L'interminable quête du parfait petit checksum : analyse comparée
p. 66 Retour d'expérience sur la gestion d’options non standard de programmes en C

Go, Rust, Carbon...

Avez-vous remarqué cette excitation autour de langages « système » (même vaguement) qui jurent pouvoir challenger la suprématie de C et C++ ? Parce que, voyez-vous, ces langages, inventés respectivement par Dennis Ritchie en 1972 et Bjarne Stroustrup en 1985 sont absolument horribles et maléfiques ! Tels de mauvais esprits sortants d’une quelconque dimension démoniaque, ils vous incitent à mal utiliser la mémoire, oublier de la libérer ou encore à ne jamais vérifier la taille des données que vous copiez. Exactement le même genre d’entités sataniques qui vous incitera à finir cet énorme paquet de chips, remettre la tonte du jardin au weekend suivant ou à regarder « encore un ou deux petits épisodes » alors que savez pertinemment que vous avez une visio hyper importante le lendemain.

D’ailleurs, si on y réfléchit un peu, il est même tout à fait probable que tout ceci soit également de la faute du C et du C++. Puisqu’on en est à retirer la responsabilité humaine de l’équation et à trouver les parfaits boucs-émissaires, autant généraliser, non ? Après tout, ce n’est pas au développeur d’être prudent, mais au langage d’être « sécurisé », « sûr » et... heu... « programmeur proof » ? Non ?

Ou alors...

On est simplement arrivé à un stade où la complexité des codes à implémenter, couplée au manque de minutie de certains développeurs (*tousse* polkit *tousse*) font qu’il est malheureusement de plus en plus nécessaire de faire du langage la nounou du programmeur...

Dans un cas comme dans l’autre, c’est assez triste.

Denis Bodor