9,90 € TTC
p. 06 Utilitaires bash d'aide au développement de shell scripts
p. 18 Une interface homme-machine hybride : terminal et navigateur HTML embarqué dans une même application C++/Qt 5
p. 24 Git au quotidien
p. 38 Tris et permutations dans les bitmaps
p. 64 Les codes fantastiques : une situation pas COMMON
p. 66 Carte PCIe CH368 et pilotage depuis l'espace utilisateur : récit d'un échec
Qu’est-ce que la programmation ?
La question est stupide, car la réponse semble évidente. Nous savons tous parfaitement en quoi consiste le fait de programmer. Mais qu’est-ce vraiment, fondamentalement, pour vous ? Et pourquoi trouvez-vous cette activité si plaisante ?
En ce qui me concerne, il s’agit non seulement de donner corps à une idée, de la matérialiser et de la perfectionner jusqu’à obtenir quelque chose de satisfaisant et d’utilisable, mais c’est également un cycle : buter sur un problème, chercher une solution, la trouver, l’implémenter et avoir son petit rush de dopamine. C’est la succession de petites victoires, découlant parfois de gros efforts, qui rend la programmation agréable. Peu importe qu’il s’agisse de débuter un projet en partant de zéro, de corriger un bug dans le code de quelqu’un d’autre ou même de viser un résultat qui n’a pas de réel intérêt autre que l’exercice lui-même. C’est le mécanisme de gratification différée, généralement proportionnelle à la difficulté rencontrée, qui rend la programmation agréable, et je dirai même psychologiquement bénéfique, sinon thérapeutique.
Ainsi, programmer c’est résoudre les problèmes soi-même, pas demander à quelqu’un, ou plus exactement à quelque chose, de le faire à votre place. Cela nous amène donc à nous demander ce que cette tendance de « vibe coding » va indubitablement retirer à notre plaisir, et donc à notre motivation. Pour moi, la réponse est claire, « vibe coder », ce n’est pas programmer, car on n’est plus le créateur, mais juste un « prompteur » (avec tout le BS que ce terme suppose).
Et tout cela, avec une absence totale de prédictibilité, car un même prompt, répété, conduira à de multiples résultats, parfois drastiquement différents. Ce qui est un énorme problème, car comprendre la logique d’un projet fait aussi partie de l’expérience du développeur. On se familiarise presque littéralement avec la manière de penser des autres contributeurs. Chose impossible à accomplir avec un LLM reposant toujours en partie sur des facteurs aléatoires, dont le modèle est mis à jour indépendamment de notre volonté et dont le comportement général ne peut être décrit que par un adjectif paradoxalement anthropomorphique : « schizophrénique ». Et ce parfois dans un même projet, sinon un même fichier source. Il n’est donc pas possible « d’entrer dans la tête du développeur » pour comprendre et faire évoluer le code, il n’y a aucune cohérence ou logique. Ainsi, là encore, point d’illumination, et la dopamine, comme le plaisir seront absents.
Le « vibe coding » est, par définition, l’antithèse du plaisir de créer. C’est déléguer à un stagiaire virtuel ce qu’on ne veut pas faire soi-même. Ça fait des choses, ça marche (parfois), ça nous arrange pour se défaire du pénible et du nécessaire... Mais ce n’est pas, et ça ne sera jamais, « programmer ».
Denis Bodor
GNU/Linux Magazine s'adresse aux professionnels et aux particuliers désireux de mieux maîtriser les techniques et problématiques liées à la programmation et à l’utilisation de solutions open source. Tous les deux mois avec ses articles techniques, la publication couvre les thématiques suivantes : programmation système, algo, bas niveau, sécurité du code, développement web...

La domotique, c'est fantastique ! Surtout quand ça ne coûte pas trop cher, que ça rend service aussi bien pour le contrôle des lumières, le suivi de la consommation électrique, le contrôle de l'environnement ou l'automatisation, et que tout cela fonctionne avec du logiciel libre, sans exfiltrer des tonnes de données privées chez un fournisseur qui se fera tôt ou tard pirater. Mais à trop vouloir jouer la carte de la sécurité, on se prive parfois de certains avantages. Trouvons donc le bon compromis pour rendre notre installation accessible, sans créer d'énormes brèches...
Que faut-il pour reproduire un badge NFC (Near Field Communication) ? Bien qu’il n’y paraisse rien, un badge NFC est en réalité une véritable prouesse d’électronique et d’informatique embarquée. Comment un simple « bout de plastique », sans aucun composant électronique visible ni alimentation, peut-il communiquer et échanger des informations avec un autre système informatique, sans même un contact physique, par le simple fait de sa proximité avec un lecteur ? Dans cet article, nous expliquerons en détail le fonctionnement d’un badge NFC et chercherons à créer un badge « maison ». Après avoir conçu une antenne adaptée, nous analyserons le protocole de communication entre le lecteur et le badge, puis tenterons de reproduire le comportement du badge pour leurrer le lecteur NFC. Tout cela nous amènera à réviser la physique des ondes électromagnétiques et à revoir plusieurs montages électroniques courants. Nous découvrirons également le périphérique RMT (Remote Controller) de l’ESP32, qui permet de générer des signaux temporels rapides et stables, tout en gérant de manière indépendante les interruptions du processeur pour synchroniser l’envoi des réponses.
Durant mes pérégrinations dans le petit monde du développement FPGA avec LiteX s'est posée une problématique intéressante, consistant à devoir écrire un support pour une interface série (UART) en n’ayant à disposition rien d'autre qu'une poignée de registres où lire ou écrire. Cet exercice, pour moi, était une phase préalable à l'implémentation d'un pilote pour un système d'exploitation, mais serait transposable à n'importe quel type d'interface reposant sur des mécanismes similaires, et ce, sur n'importe quel MCU ou SoC, actuel ou ancien. Faisons donc connaissance avec l'UART LiteX, voulez-vous ?