9,70 € TTC
p. 06 Advent of code, jour 7
p. 12 Quelques réalisations basées sur l'algorithme PEAC
p. 30 Rocket : construisez une API REST en Rust
p. 38 GitHub équipé d’un Sonar
p. 54 Modularité de l'authentification sous OpenBSD
p. 64 Visualisez les données grâce à l’alphabet Braille !
p. 66 Les codes fantastiques : fusion en chaîne
p. 68 aStrA : vers de vraies chaînes de caractères en C !
John Connor n’avait pas pensé à ça...
Un récent billet [1] de Niccolò Venerandi, développeur KDE Plasma, met l’accent sur un problème impactant certains sites web : les bots/scrapers/crawlers IA/LLM les surchargent au point d’en pénaliser le fonctionnement, ainsi que celui des projets associés.
Sans trop de surprise, l’origine de la perturbation semble clairement et principalement venir d’entités chinoises, choisissant d’ignorer totalement les directives du robots.txt et allant parfois même jusqu’à délibérément ajuster leur user agent pour contourner les mesures de protection. Les effets sont si conséquents que le projet GNOME a décidé d’utiliser Anubis [2] fin 2024, présentant un challenge au navigateur, lui demandant une « preuve de travail » pour lui autoriser l’accès, et ce, de façon transparente pour un vrai humain.
Le billet détaille clairement les choses, chiffres à l’appui et on en arrive à ce demander si la « théorie de l’Internet Mort », à défaut d’être déjà juste, n’est pas sur le point de se vérifier définitivement. Cela me fait tristement penser à Usenet, longtemps source de connaissances et d’interactions (souvenez-vous des recettes de FMBL) qui n’est aujourd’hui plus que l’ombre de lui-même, après n’être devenu un temps rien d’autre qu’un média d’échange de volumineuses données binaires (NZB, Yenc, uuencode, etc.).
Aujourd’hui, la plupart des ISP n’offrent même plus d’accès à Usenet/NNTP et la perspective que le Web puisse avoir une destinée similaire, ses utilisateurs ne le percevant plus qu’au travers d’assistants personnels, me paraît aussi déprimant que plausible. Peut-être faudra-t-il, à ce moment, revenir à quelque chose de proche des BBS d’antan, chiffrés, protégés et exclusifs, sur fond de « si vous accédez à ce serveur, vous êtes la résistance »...
Denis Bodor
[1] https://thelibre.news/foss-infrastructure-is-under-attack-by-ai-companies/
[2] https://github.com/TecharoHQ/anubis
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...

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 ! ».
Si vous croyez que le format ASCIIZ (aussi appelé « chaîne de caractères à terminateur nul » à la base du langage C et d’UNIX) est le pire péché originel de l’informatique, accrochez-vous. Il est amplifié par un autre péché bien plus grave, commis au nom du minimalisme, excusé au nom de la compatibilité et perpétué par l’oubli des alternatives. Si vous avez lu l’article de mars 2023 [1] jusqu’au bout, vous avez probablement compris que la plupart des langages de programmation actuels n’utilisent qu’une seule pile. C’est la source de nombreux problèmes (de sûreté, de sécurité, de complexité et bien d’autres) aux origines de failles variées (représentant peut-être un cinquième des CVE) que nous sommes habitués à mitiger, sans les résoudre vraiment. Dans cette première partie lovecraftienne, nous irons jusqu’au fond de l’impasse pour démontrer l’absurdité, les difficultés et les dangers imposés par ce système.
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 !