Développer ses petits outils, quel que soit le langage, est une activité mariant l'utile à l'agréable et l’on se satisfait généralement d'une exécution locale ou d'une simple copie dans un endroit quelconque pointé par le PATH. Lorsque les outils en question deviennent potentiellement intéressants pour plus d'une personne, on prend son courage à deux mains et on en diffuse les sources publiquement (via GitLab ou GitHub, par exemple). Et arrive ensuite la problématique d'intégration au système et donc l'implication d'un système de gestion de paquets...

Quel administrateur système n'a jamais cherché à comparer des fichiers /etc/hosts ? Si cela vous est déjà arrivé, vous n'avez probablement pas trouvé l'outil adéquat, capable de reconnaître la syntaxe de ces fichiers. Mais désormais cet outil existe, développé pour ce besoin spécifique, en C/lex/yacc sous forme de module RPN, et nous allons vous en expliquer le principe de fonctionnement et le mode d'emploi.

Derrière ce titre très générique se cache en réalité la poursuite d'un projet farfelu consistant à redonner vie à un préhistorique Pentium 233 MMX. Dans un premier article paru dans le hors-série 122 [0], nous avons reconstruit une release FreeBSD 13.1 pour cette machine et dans un précédent numéro, nous avons fait connaissance avec la création de ports permettant d'intégrer ses propres développements au système de façon propre et ordonnée. Il est temps maintenant de combiner ces deux expériences pour produire un lot de paquets binaires à destination du Pentium, composé à la fois de ports officiels et des nôtres.

Quiconque s'intéresse un tant soit peu au design web entend parler de Bootstrap depuis longtemps. Figure incontournable dans le domaine, il a su évoluer pour ne pas se laisser dépasser. Regardons un peu le chemin parcouru avant d'examiner les bases de son utilisation aujourd'hui.

C’est l’histoire d’un geek qui, à force de tourner en rond, finit un jour par tomber sur un nouvel algorithme de checksum qui résout les soucis des algorithmes connus. Il serait content que d’autres puissent en profiter, mais on lui signifie qu’il faut déjà prouver que ce nouveau venu est meilleur que les autres. Et puis à quoi bon chercher plus loin, puisque ce qui existe est déjà standardisé, étudié et répandu, et leurs défauts sont « acceptés ». Afin de gagner la confiance du public, notre geek se remet donc à publier des articles sur les checksums [1] et les corps de Galois [2]. Ce faisant, il se retrouve sur des terrains mathématiques qui sortent du domaine initial, mais cela montre aussi les liens avec d’autres applications comme les brouilleurs ou les générateurs de nombres pseudo-aléatoires. Si nous arrivions à bien cerner ces derniers, il deviendrait alors possible de caractériser les autres. Voici donc une exploration un peu plus abstraite que d’habitude, qui permet de faire d’une pierre plusieurs coups : un pont entre de nombreux domaines.

Le processeur de macros m4, bien qu'étant un outil apparu dans les débuts d'UNIX, est généralement très peu utilisé. Son apparente complexité peut expliquer pourquoi il a aussi peu d'adeptes. Pourtant, son utilisation n'est pas aussi compliquée qu'il y paraît. Nous allons la démystifier dans cet article, de façon à tenter de rendre l'outil un peu plus populaire.

Le benchmarking, ou mesure de la performance d’un morceau de code est devenu impossible alors qu’il reste absolument indispensable pour toute démarche d’optimisation. Comment peut-on savoir si une modification va l’accélérer, et dans quelle mesure ? Aujourd’hui, ce n’est en fait plus la vitesse absolue qui compte, mais la différence entre deux versions qui nous guidera.

Que de racolage en si peu de mots. Et pourtant si, c’est bien la promesse de cet article, comment parvenir à construire un système d’exploitation fonctionnel en moins de… 10 mégabits. Quelle est cette sorcellerie ? En utilisant une fonctionnalité prévue, mais pas utilisée à cet escient par le noyau NetBSD, nous allons lui faire subir un régime drastique !

Peu de fonctions de la bibliothèque standard C auront cumulé autant de ratés (noms piégés, conception peu soignée, fonctionnement inconsistant, ambiguïté, sécurité défaillante) que les fonctions dédiées (ou supposées dédiées) à la copie ou concaténation de chaînes de caractères. Il s’agit des fonctions strcpy/strcat et strncpy/strncat. Il a été suggéré d’utiliser à leur place d’autres fonctions comme le couple strlcpy/strlcat ou bien la fonction snprintf mais au final, plusieurs problèmes restent mal ou non résolus.