LIVRAISON OFFERTE en France métropolitaine
Janvier / Février 2026

GNU/Linux Magazine 279

Utilisez Git au quotidien !

  • Maîtrise des opérations courantes
  • Scénarios et cas d’usage
  • Se sortir des situations épineuses

En savoir plus

9,70 € TTC

Anciens Numéros

LIVRAISON OFFERTE en France Métropolitaine à partir de 50€
GNU/Linux Magazine 279

GNU/Linux Magazine 279

Janvier / Février 2026
9,70 €
GNU/Linux Magazine 278

GNU/Linux Magazine 278

Novembre / Décembre 2025
9,70 €
GNU/Linux Magazine 277

GNU/Linux Magazine 277

Septembre / Octobre 2025
9,70 €
GNU/Linux Magazine 276

GNU/Linux Magazine 276

Juillet / Août 2025
9,70 €
GNU/Linux Magazine 275
9,70 €
GNU/Linux Magazine 274

GNU/Linux Magazine 274

Mars / Avril 2025
9,70 €
GNU/Linux Magazine 273

GNU/Linux Magazine 273

Janvier / Février 2025
9,70 €
GNU/Linux Magazine 272

GNU/Linux Magazine 272

Novembre / Décembre 2024
9,70 €
SOMMAIRE :


Système & Libs

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

Autour du code

p. 24   Git au quotidien

Science & Algo

p. 38   Tris et permutations dans les bitmaps

Bas niveau & Reverse

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

ÉDITO

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

Le magazine de référence technique pour les développeurs sur systèmes open source et les ingénieurs R&D !

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...

Embarquez un peu de Lua dans vos projets C
GNU/Linux Magazine n°269

Soyons clairs, je ne suis pas fan de Lua en tant que langage de programmation. Le simple fait que les tableaux débutent à l'indice 1 me perturbe totalement et constitue pour moi une véritable aberration. Mais, d'un autre côté, Lua est aussi le langage par excellence lorsqu'il s'agit d'embarquer des fonctionnalités de scripting au sein d'une application ou d'un outil. Du moins, c'est ce que tend à montrer sa popularité dans ce domaine et, si l'on n’a jamais tenté l'expérience, on peut se demander pourquoi. La réponse est évidente après quelques lignes de code et on se surprend soi-même à dire, à haute voix qui plus est, « Ah ! Mais c'est excellent, en fait ! ».

Écrire son premier pilote pour OpenBSD
GNU/Linux Magazine n°269

Dans un précédent article [1] paru dans le numéro 260, nous avions fait connaissance avec le développement noyau du côté de NetBSD. Remettons le couvert aujourd'hui, mais en nous penchant sur OpenBSD qui, de bien des manières et sur bien des plans est drastiquement différent des autres systèmes de la famille des héritiers de l'historique BSD que sont NetBSD, FreeBSD ou en encore DragonFly BSD. À commencer par le fait qu'il n'y a pas de modules kernel (LKM) dans OpenBSD...

Manipulons les caractères avec iconv
GNU/Linux Magazine n°269

Au détour d'un petit projet incluant des échanges USB avec un adaptateur série utilisant une puce FTDI FT232R, j'ai rencontré un problème susceptible de survenir dans diverses situations. Même si aujourd'hui UTF-8 semble avoir toujours été présent dans nos terminaux, éditeurs, codes et que sais-je encore, les utilisateurs et programmeurs les plus aguerris se souviennent sans peine de la souffrance vécue lors de la transition depuis le bon vieux Latin1 (alias iso-8859-1). Mais la dure réalité est la suivante : UTF-8 n'est pas partout !

Ce magazine est intégralement disponible sur Linux Magazine Connect
© 2026 - LES EDITIONS DIAMOND