Bodor Denis

Nous avons déjà, par le passé, exploré les technologies NFC [1] dans les pages du magazine, et récemment, fait connaissance avec la programmation d'un petit outil en ligne de commandes pour les tags ST25 de chez STMicroelectronics [2] ou encore détourné un jouet pour enfant [3] basé sur cette même technologie. Il est temps maintenant de se pencher sur quelque chose d'un peu plus sérieux, un peu plus complexe et surtout d'un peu plus utile : un outil permettant de configurer un token NFC dédié à l'authentification à deux facteurs.

Développer ses petits outils, quel que soit le langage, est une activité mariant l'utile à l'agréable et l’on se satisfait généralement d'une exécution locale ou d'une simple copie dans un endroit quelconque pointé par le PATH. Lorsque les outils en question deviennent potentiellement intéressants pour plus d'une personne, on prend son courage à deux mains et on en diffuse les sources publiquement (via GitLab ou GitHub, par exemple). Et arrive ensuite la problématique d'intégration au système et donc l'implication d'un système de gestion de paquets...

Dans Hackable 40 [1], nous avons fait connaissance avec la Black Magic Probe, un outil de mise au point faisant fonctionner un serveur GDB et permettant de se passer totalement d'OpenOCD pour contrôler l'exécution d'un code sur un microcontrôleur ARM. Le buzz récent autour du Flipper Zero, un « multi-tool pour geeks », ainsi que quelques connaissances qui se reconnaîtront m'ont fait me pencher sur le « Wi-Fi Debugger Module » de ce périphérique...

Recompiler et reconstruire tout un OS n'est généralement plus quelque chose qu'on fait très souvent de nos jours. Les cas sont généralement limités à quelques domaines ou obligations techniques, parmi lesquels l'embarqué, le maintien de solutions legacy, ou la simple perversité. FreeBSD, comme GNU/Linux, n'échappe pas à cette règle et bien des fois, les images binaires (USB, ISO, archives, etc.) sont suffisantes... Sauf quand ce n'est pas le cas.

Oui, oui. Vous avez bien lu, je parle de DOS là, le vieux ou le nouveau DOS (MS-DOS, FreeDOS, DR-DOS, etc.), ce système qui paraît aujourd'hui presque préhistorique, non multi-utilisateur et non multitâche (non, les TSR, ça ne compte pas). Il existe bien des solutions pour développer pour ce système, dont le très connu DJGPP, le portage de GCC par DJ Delorie, mais ce dont il est question aujourd'hui est le compilateur Watcom C/C++, et plus précisément Open Watcom, ainsi que son « DOS extender » DOS/4GW rendu célèbre en particulier par Doom.

Dans un thread récent sur la LKML (Linux Kernel Mailing List), Linus soulevait la problématique du support d'anciens processeurs et le fait que le code noyau supportant ces matériels était un véritable nid à bugs, du fait du désintérêt total à la fois des développeurs et des utilisateurs. Linux n'est pas le seul noyau/système dans cette situation et FreeBSD, par exemple, a également réglé le type minimum de CPU sur architecture i386 de 486 à 686 avec la release 13.0 mi 2022 pour la distribution binaire (construire pour 486 ou Pentium reste possible, cf. article dans ce numéro).

Voici quelques saines lectures pour vos soirées. Ces ouvrages ne sont pas nécessairement les plus récents, mais méritent de trouver place dans la bibliothèque de tout développeur qui se respecte, selon ses affinités personnelles bien sûr. Il vous faudra certes un minimum de pratique dans la langue de Shakespeare pour les « consommer », mais l’effort en vaut réellement la chandelle au regard de leur contenu...

Avez-vous remarqué que nombre de nouveaux outils en ligne de commandes, très populaires, sont tous écrits dans des langages tout aussi nouveaux ?

L'écriture de pilotes et de modules noyau Linux est documentée en long, en large et en travers sous bien des formes, et ce depuis quelque temps déjà. Pourtant, ce n'est pas là que l'énergie et le temps nécessaire pour ajouter une fonctionnalité ou le support d'un matériel seront obligatoirement les mieux investis. La quantité de développeurs soumettant des contributions au noyau Linux est énorme et très souvent, la question consistant à se demander si un matériel est pris en charge ne se pose même plus. Quelqu'un a forcément développé quelque chose avant que vous ne rencontriez un tel problème. Ce n'est pas forcément le cas pour d'autres systèmes, et NetBSD en particulier. Là, apporter sa pierre à l'édifice est sans doute plus intéressant. Mais avant de pouvoir courir, il faut savoir marcher...