Bodor Denis

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

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.

Je suis utilisateur de Vi/Vim depuis des dizaines d'années et changer ses habitudes n'est pas chose facile. Un élément déclencheur est souvent nécessaire et le mien aura été un essai de Visual Studio Code pour du développement sur microcontrôleur avec PlatformIO. J'ai donc décidé de quitter Vim pour passer à... Neovim. Hé oui, ne vous y trompez pas, car même si VSCode s'avère effectivement agréable, voire proche d'une expérience Vi avec les bons plug-ins, et qu'on s'habitue facilement au confort de la complétion « IntelliSense » et de l'affichage des prototypes de fonctions, cet IDE graphique ne sera jamais Vi. Au contraire, il pousse simplement à faire en sorte que son Vi adopte des fonctionnalités qu'il ne possède pas nativement. Et c'est précisément ce dont il est question ici.

« Oui, moi je programme en HTML ! »

Voici une affirmation généralement corrigée d'un vif « HTML est un langage de description, pas de programmation » par la plupart des personnes ayant un minimum d'expérience et de connaissances en ce domaine. S'en suivent généralement diverses explications plus ou moins animées autour de ce qu'est ou non un langage de programmation, qui a droit au titre ronflant de « programmeur » et qui dénigre honteusement le travail de qui...

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

En ces temps difficiles de pénurie de framboises, recycler une carte existante, quel que soit son modèle, est quelque chose de courant. Plus question en ce moment d'installer un système et de laisser traîner le tout dans un coin, après quelques tests. Même la multiplication des cartes microSD ne solutionne pas le problème, en particulier s'il faut acheter des supports de qualité pour ne pas être limité en performances. La conséquence est claire et tient en quelques mots : installation, installation et re-installation !