Comment tirer le meilleur parti des divers langages à notre disposition, entre vitesse de prototypage de Python ou GNU Octave et vitesse d’exécution de C ? Nous allons échanger des données entre des fonctions écrites dans ces langages, soit par socket du réseau soit par bibliothèques dynamiques.

Ces dernières années, les frameworks JavaScript se sont multipliés à foison, apportant toujours plus de fonctionnalités et de réactivité. Mais cette effervescence a pour conséquence une plus grande difficulté à comprendre l'offre et un accroissement de technicité. Alors, pourquoi ajouter un autre framework ? Pour retrouver la simplicité, découvrez Alpine.js, ou comment utiliser JavaScript sans écrire de JavaScript.

Lorsqu'on fait connaissance avec l'un des systèmes héritiers du BSD d'origine, à savoir FreeBSD, NetBSD ou encore OpenBSD, tout en ayant une certaine expérience de GNU/Linux, il est relativement facile de retrouver ses petits. Certes, depuis quelques années, le système d'init et la gestion des services de GNU/Linux se sont drastiquement écartés des principes propres à la philosophie Unix, jusqu'alors respectés par GNU/Linux. Dans l'ensemble, la transition est relativement aisée, mais il y a cependant un point sur lequel les différences sont telles que quelques explications s'avèrent nécessaires : la gestion des périphériques « hotplug » (USB) et de leurs permissions.

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

Lorsque l’on parle de programmation sécurisée, on pense d’abord à un dépassement d’indice d’un tableau ou à des droits d’accès non respectés, puisque ces aspects sont visibles par le programmeur. Par contre, la pile est sous le contrôle absolu du compilateur et le contrat implicite est que « ça fonctionne » tant que nous le laissons faire son travail, qui est de plus en plus alambiqué. L’article précédent [1] détaillait de façon lovecraftienne les soucis de flexibilité et de sécurité inhérents au modèle de programmation à une seule pile, utilisé par (quasiment) tous les compilateurs actuels. J’ai amalgamé tous ces problèmes dans le terme « Single Stack Syndrome », mais il n’y a pas que le C ou le x86 dans la vie ! Nous pouvons trouver des inspirations dans d’autres langages, d’autres architectures et d’autres ères.

Dans GLMF 265, je vous avais annoncé que la fonctionnalité « boot PVH » du noyau NetBSD était « en cours d’étude », ce que je n’avais pas mentionné, c’est que cette étude était menée… par votre serviteur avec pour plan de l’exposer dans ces colonnes.

L’émulation a le vent en poupe ces dernières années. Un intérêt sans doute renforcé par la bulle spéculative autour du retrogaming qui rend l’acquisition de vieilles machines ou de vieux jeux hors de prix. Nous allons voir dans cet article comment développer facilement un émulateur. Nous en profiterons même pour concevoir notre propre machine à émuler.

La mémoire cache est un composant majeur des processeurs et sa mauvaise utilisation peut entraîner une baisse importante des performances d’un programme. Nous allons voir dans cet article quelques astuces pour mesurer les performances liées aux caches et éviter certains écueils.

Le C est sur la sellette ces derniers temps, car, voyez-vous, c'est un langage peu sûr, qui laisse faire tout et n'importe quoi au programmeur. Et comme on ne peut pas faire confiance aux programmeurs pour s'occuper proprement de la mémoire qui leur est gracieusement confiée, il est important de promptement leur confisquer ce langage dangereux, permissif, et disons-le franchement, totalement maléfique. Si, si ! J'adhère totalement à cette vision et, moi aussi, je vais changer de langage préféré pour assurer ma sécurité, protéger les chatons et sauver les petits enfants. Au revoir le méchant C, bonjour le gentil assembleur !