Bodor Denis

De nos jours, vérifier l'authenticité d'un message, qu'il s'agisse de celui provenant d'un humain ou d'une machine est devenu presque quelque chose de totalement obligatoire. Tout un tas de mécanismes sont d'ores et déjà en place pour bon nombre de protocoles et de formes d'échanges, qu'il s'agisse du certificat d'un site web, d'un mail signé avec OpenPGP, d'une authentification pour une connexion distante avec SSH, et j'en passe. Mais qu'en est-il pour les petites choses, comme une simple ligne de texte, une URL ou la donnée embarquée dans un QRcode ?

Vous avez remarqué que le FUD (Fear, Uncertainty and Doubt), tant utilisé par le passé contre GNU/Linux et le logiciel libre en général, est devenu la norme pour la promotion de bon nombre de solutions et services en ligne ?

Dans un précédent article [1], nous avons vu comment il était possible, avec une Raspberry Pi Pico, de créer relativement facilement un périphérique USB au comportement arbitrairement défini. Mais bien avant l'arrivée du microcontrôleur RP2040, il était déjà possible de faire cela depuis bien longtemps, trèèèèèès longtemps même. Et je ne parle pas d'Arduino (Leonardo en l'occurrence et son ATmega32u4), mais d'un composant que vous possédez peut-être déjà, sans le savoir, dans votre boîte à outils : l'EZ-USB FX2LP.

Une vidéo récente sur la chaîne secondaire de Matthias Wandel [1] m'a récemment fait vérifier presque l'ensemble des câbles que j'utilise pour mes montages et autres expériences. En effet, Matthias, qui généralement diffuse du contenu autour du travail du bois, a constaté que ses câbles munis de pinces, achetés très récemment, présentaient une résistance relativement surprenante, quelque 300 mΩ pour 15 cm, ce qui n'est peut-être pas un problème pour des signaux (selon la fréquence), mais en est clairement un pour une alimentation.

Lorsqu'il s'agit de tirer le maximum des ressources à disposition d'une plateforme, en particulier dans l'embarqué, le processeur n'est généralement pas souvent la solution la plus adaptée. Du matériel dédié comme les accélérateurs matériels, en particulier pour les calculs matriciels ou la cryptographie, viennent souvent assister le processeur et l'alléger des tâches demandeuses en calcul. L'une des options possibles dans ces situations est l'utilisation du GPU, via des frameworks dédiés. Une humble Raspberry Pi peut être un excellent terrain de découverte pour prendre en main ce type de technologies.

Si pour vous aussi votre paranoïa et votre hantise de passer pour un clown vous poussent à tester, retester, et re-retester ce que vous faites avant d'envisager éventuellement soumettre le résultat de votre travail entre les mains de gens bien plus compétents que vous, sachez que c'est normal et que vous n'êtes pas seul. Le syndrome est même parfaitement décrit et recommandé dans la documentation d'OpenBSD [1]. Pour assurer mes arrières, j'ai donc décidé de systématiquement tenter de construire mes ports sur une version vierge et fraîchement installée du système, dans une VM fonctionnant sur la machine de développement. L'occasion parfaite pour découvrir l'hyperviseur OpenBSD...

LiteX est un projet qui aurait dû faire l'objet d'un article depuis bien longtemps, puisqu'il s'agit sans doute de la façon la plus simple d'aborder le monde des circuits logiques programmables (PLD), et des FPGA en particulier. Plus exactement, ce framework permet de composer son matériel avec des briques élémentaires, sans utiliser de Verilog ou de VHDL et d'obtenir, au final, un système embarqué ou un périphérique sur mesure qu'on peut ensuite programmer. Découvrons cela...

Contribuer à des projets open source signifie implicitement rejoindre une communauté de développeurs et communiquer de façon efficace via l'infrastructure prédatant votre subite envie d'apporter votre pierre à l'édifice. Certains projets optent ou migrent vers des choses comme GitHub, Slack, Discord, et d'autres préfèrent raisonnablement rester sur Git, CVS, phpBB, Trac et surtout des listes de diffusion. Et qui dit « listes de diffusion » dit forcément « utiliser un MUA » (Mail User Agent) digne de ce nom, comme Mutt (ou NeoMutt) ». Seulement voilà, quand votre fournisseur de services de messagerie électronique impose des restrictions, c'est le drame !

OpenBSD est un système spécial, adorablement spécial même, et parmi ses spécificités, on trouve par exemple le fait de privilégier la compilation native, par opposition à la compilation croisée. Je n'invente rien, c'est dans la documentation [1]. Ceci dit, même si les raisons évoquées sont parfaitement compréhensibles et légitimes, ce n'est pas parce que quelque chose n'est pas recommandé qu'il ne faut pas le faire. Cross-compilons donc un noyau OpenBSD pour arm64 depuis amd64...