Émission 426 du 1 février 2026

• Download:
• Podcasts Underscore72 MB

Actu

Software Heritage fête ses 10 ans

Une interview de Bastien Guerry nous explique ce projet de préservation du patrimoine applicatif.

Sortie de Wine version 11

Parmi les nouveautés :

• il peut faire tourner les applis 32 bits même si l’OS hôte ne supporte plus le 32 bits, avec un seul chargeur (plus besoin de win64), et peut même lancer les applications 16bits.
• il implémente (enfin) NTSync, qui émule les primitives de synchronisation de Windows directement depuis le noyau Linux, donne de bien meilleures performances qu’en les simulant en espace utilisateur. Wine rattrape donc l’avance qu’avait pris Proton. Il faut peut-être encore charger le module par modprobe suivant votre distribution.

L’État veut renforcer ses outils collaboratifs souverains du Ministère des Armées

La DINUM et les acteurs du numérique de défense se sont engagés pour déployer et adapter les outils de LaSuite aux besoins des armées, dans un contexte de renforcement de la souveraineté numérique. Et l’OpenBar Microsoft, ça finit quand ?

Chiptune: Bacon of hope by Maze/Desire

1er amiga demo à la Gerp 26

Sujet : Chronique Geek : Unix

Bonjour, et bienvenue dans cette nouvelle chronique geek hors-série! Aujourd’hui, on va parler d’Unix, de Linux et de plein d’autres choses

La première fois que j’entend parler de Linux fût lors de nos soirées réseau Electron BBS. Hervé nous parle de cet Unix gratuit qui est compatible POSIX et qui fait déjà presque tout comme un grand. C’est encore très rock’n’roll mais il semblait déjà super intéressé. Je n’avais aucune idée de ce qu’était Linux et je n’étais pas convaincu de ses avantages réels. Après tout, avec le DPMI on avait déjà nos programmes en 32 bits et de la mémoire virtuelle sous MS-DOS, qu’est-ce qu’on pouvait vouloir de plus? Je n’étais pas convaincu du fameux multi-tâche préemptif. Quand on n’a qu’un seul processeur, ça reste de toutes façons tricher.

Les années passent, je découvre Unix-AIX (celui d’IBM) à l’université et j’ai toujours autant de mal à voir la différence avec MS-DOS. Il y a bien le multi-tâche et la gestion de plusieurs processeurs mais j’avais aussi ça sur mon PC. Le multi-tâche préemptif était accessible sous DOS et même Windows 3.11 grâce à l’ajout de pilotes additionnels. Rendez-vous compte, on pouvait enfin faire quelque chose d’autre pendant la copie d’une disquette sur le disque dur, ce qui d’ailleurs se faisaient déjà sur Atari ou Amiga avec le même procédé, une bête utilisation des DMA (donc rien à voir avec le véritable multi-tâches). Reste qu’à cette époque, on avait de toutes façons un seul écran et souvent à peine assez de mémoire pour bien faire fonctionner le programme en cours.

Sur le mini-ordinateur de l’université (pour rappel, mini, c’est plus grand que micro, cet ordinateur était grand comme un frigo américain), on avait un multitâche balaise, même si il était assisté par tous les terminaux qui s’occupaient de l’affichage, de l’interface avec l’utilisateur. Oui, là c’était bluffant, une centaine de personne à utiliser la même machine, en même temps. Mais tel qu’on nous l’avait présenté en cours de programmation, ça ne me semblait pas génial non plus. On nous avait enseigné le FORK qui consiste à dupliquer un programme en mémoire ce qui était ultra-gourmand en ressources. L’interaction était elle aussi limitée.

On n’avait pas vraiment moyen d’exploiter plusieurs processeurs au sein d’un même programme afin de distribuer les calculs. Le FORK réalise une copie complète du programme qui l’initie puis lui donne un nouvel ID (chaque processus a son propre nom sous forme de numéro, je ne suis pas un numéroooooo, ben si!). On a donc un programme père et un programme fils, la seule différence entre les deux est cet ID. En fait, ce sont plutôt des clones. Et comme le clonage est très coûteux, on s’en servait pour de très gros calculs. Les processus pouvaient discuter entre eux très sommairement avec des signaux et des fonctions pour s’attendre mais il n’existait pas encore toute la panoplie propre aux threads, en tous cas on ne nous en a pas parlé.

Les Threads apparaissent en 1995, autant dire qu’à part ceux dans le secret des dieux, on n’était pas au courant que ça existait, les profs encore moins. Ça par contre c’était puissant mais je le découvrirai bien plus tard.

En attendant, on utilisait la lourdeur du FORK pour faire des blagues à l’université. On lançait un programme qui allouait plein de mémoire et réalisait des opérations dedans et se multipliait. On avait dans un coin un moniteur de ressources qui donnait l’occupation de la machine centrale. Et on regardait la motte de beurre se former sur le graphique, pendant qu’une clameur venait de toutes les salles à base de « oh noooooon, ça a encore planté ». Il fallait rapidement tuer les processus pour ne pas se faire attraper par l’administrateur système. Nous avions sobrement appelé ce programme BATO, parce que ça faisait ramer.

Chez Intel on commence à voir apparaître depuis le Pentium Pro des cartes-mères à deux processeurs. Oui, parce que non seulement il faut une blinde de mémoire pour profiter du multi-tâches, mais si on veut faire du vrai multi-tâche performant, c’est mieux d’avoir deux processeurs. Mais combien ça coûte tout ça? Une raison de plus pour moi d’avoir attendu jusqu’aux premiers processeurs multi-coeurs d’Intel, les Core 2 Duo. Clairement, les cartes-mères bi-Pentium Pro étaient réservées aux entreprises, ces processeurs étaient des Rolls, de l’or partout et un cache de second niveau était intégré, là encore une rareté. Je ne sais même pas si Windows NT pouvait fonctionner dessus. J’avais utilisé ce genre de machine au début des années 2000 et c’était un Unix qui était dessus, de mémoire AIX de chez IBM.

Au long de ma carrière, je ne commence à voir apparaître l’utilisation du multi-coeur que vers la fin des années 2000. Un spécialiste avait été dépêché pour paralléliser un code critique (vous vous rappelez l’histoire des 2000 magasins qui renvoient 30.000 références à commander dans l’heure? C’était pour ça). Je crois avoir un peu pleuré devant l’optimisation à base de… …Fork! Ah ça fonctionnait hein mais bon, 15 ans après la création des threads, ça faisait mal au cœur de voir un Fork dans un programme. Heureusement que les machines avaient bien évolué et qu’on était dans des quantités de mémoire qui se comptaient en Giga-octets. Mais je me méfiais un peu de tout ça.

J’avais vu quelques années auparavant une grosse refonte logiciel, passant d’un code rustique et optimisé sur une toute petite machine Pentium-Pro à du code en Java, sur 7 serveurs monstrueux, bourrés de mémoire et de processeurs ultra-balaises, rien n’y avait fait, le passage au Java avait complètement détruit les performances.

Bon, qu’importe, je crois que c’est cette vision du Fork qui m’avait fait une piqûre de rappel sur le multi-tâche et m’avait motivé à upgrader mon Pentium4 en Core-2 DUO. À moi les joies du multi-tâche! Comme je le disais à la fin d’une précédente chronique, j’installe Linux sur cette nouvelle machine et je commence à virtualiser Windows pour continuer à utiliser Photoshop. C’est bien agréable ces machines virtuelles, surtout Windows! On peut surfer sur Internet depuis Linux et la machine virtuelle est cloisonnée, coupé du réseau, ne fait tourner que Photoshop et je récupère mes photos grâce à un répertoire partagé entre la machine virtuelle et l’hôte. Je n’étais même plus obligé de mettre Windows à jour ou de le vérifier contre les virus, il était coupé du monde, donc parfaitement immunisé. L’autre avantage de Linux et pas des moindres, la plupart des grosses distributions de l’époque étaient livrées avec le compilateur C installé, et gratuit comme le reste. Même si Linux s’était démocratisé avec des distributions jolies, ergonomiques, on sentait que tout était fait pour plaire aux programmeurs, et surtout aux programmeurs C.

Quelque temps plus tard, un copain d’exploration urbaine me demande si je connais des demo-makers?

Hey, oh! Tu sais à qui tu parles? Le demomaking, c’est mouaaaaaaa! Heu… pardon…

Dis toujours, je vais voir si je peux t’aider. C’est que je n’ai toujours pas touché à la programmation des cartes 3D, je n’ai aucune idée de ce qu’on utilise à ce moment pour faire des démos. Est-ce que j’allais pouvoir l’aider? Lucas fait beaucoup de photographies, on s’est connu sur un toit parisien, je crois que c’était celui du Grand Palais quand il y avait des travaux de réfection et qu’on avait passé la nuit là haut. Toujours amateur de photographies, il voulait monter un projet interactif pour exposer ses photos. Génial. Le concept est assez simple, des corps nus tous photographiés sous le même angle, charge au programme de mélanger les corps pour créer des chimères humaines. Il avait sacrément bossé son projet, en plus de la centaine de modèles, il avait rédigé un poème pour chaque corps. Il fallait donc créer le visuel et mélanger les vers des poèmes pour associer à chaque création une poésie unique mélangeant les vers respectifs de chaque morceaux de corps.

100 corps mélangés en 9 tranches nous donnaient un nombre imprononçable de combinaisons. Environ 967 milliards de milliards de combinaisons, je vous passe les petits chiffres.

En tous cas, on est au delà de la démo. Il veut une interactivité avec les visiteurs et que ça soit projeté dans une très haute résolution. Il va falloir sacrément optimiser. Quand je vous dit qu’on y revient toujours: Optimisations

Je bachote alors tout ce que je trouve sur les threads. Qu’est-ce que sont les Threads? Pour faire du multi-tâche, le FORK est rudimentaire et aussi peu pratique que performant. Les Threads permettent d’utiliser plusieurs processus au sein d’un même programme, sans le cloner. Seul le code et la pile sont clonés, l’ensemble des variables globales (ou dynamiques) du programme reste en commun et est partagé avec les threads. C’est là que ça devient rigolo car si on veut travailler sur un tableau, il est possible que deux threads sur deux processeurs différents puissent lire la même zone. Par contre, quand il s’agit d’écrire, ça se complique et des conflits peuvent apparaître. Quel processeur aurait la priorité à l’écriture? Bon, ce sont de toutes façons de mauvaises pratiques, personne ne fait ça. Personne ne fait ça hein? Hein?

Le thread est donc plus rapide à initialiser et comme les threads travaillent sur la méme mémoire, il n’y a en gros qu’à borner la zone de travail de chaque thread. Le premier s’occupera du début du tableau, le deuxième de la fin. Pour dialoguer entre eux, les threads ont à disposition tout un arsenal de fonctions pour communiquer, des mutex, des sémaphores, des verrouillages, et aussi les bonnes pratiques!

Les threads sont lancés par le programme principal qui continue de tourner dans son coin, on peut donc créer des threads pour faire tout et n’importe quoi, le programme principal vaque à ses occupation et il revient voir si les threads ont terminé. Quand ils ont terminé, il peut utiliser le résultat à sa guise, c’est le principe général.

Pour réaliser le programme de Lucas, les threads vont me sauver. En effet, je n’ai ni plus ni moins besoin d’une sorte de photoshop mais rapide et que je puisse utiliser depuis mon programme principal.

Je commence alors à écrire des fonctions multi-threadées. Il m’en faut pour découper, copier, tourner, déformer des morceaux d’images. Ensuite, en définissant les zones sur chaque corps à l’avance, on saura comment déformer chaque morceau de corps pour les adapter les uns les autres. Pour la partie son, Lucas me fournira un millier de fichiers audio correspondant aux milliers de vers des poésies. Confidentialité oblige, les données de la démo seront chiffrées afin qu’il ne soit pas possible (facilement hein, rien n’est impossible) de reconstruire les corps. J’ajoute des règles de gestion dans la génération des corps pour que deux morceaux consécutifs ne fassent pas partie du même corps et que le sexe affiché ne soit jamais celui du visage.

Pour l’interaction, on ajoutera un pavé numérique déporté en USB, l’ordinateur gérant la performance étant logé à l’intérieur d’une borne en bois avec le vidéo-projecteur. Ça c’était du show!

Une fois qu’on goûte un peu à la programmation multi-coeur, c’est assez enivrant. Avec deux cœurs on double les performances, avec 4 cœurs, on arrive quasiment à quadrupler…

Si on ajoute l’utilisation d’instructions vectorielles type MMX, SSE, AVX… les instructions vectorielles, j’ai oublié de parler des instructions vectorielles…

Avant de multiplier les cœurs, des instructions de travail en groupe avaient été ajoutées aux processeurs. D’abord le MMX sur les Pentium, ensuite le 3DNow sur AMD, qu’Intel n’a pas suivi et les fabricants ont fini par s’entendre sur un jeu d’instructions commun: le SSE puis l’AVX. Sous ces dénominations reposent un même principe. Utiliser des registres très larges. D’abord 64 bits, puis 128 bits et même maintenant 512 bits. Ces registres sont découpés de façon logique en sous-registres. Ainsi, si on a un tableau de valeurs 16 bits, on peut charger 32 valeurs dans un seul registre AVX-512. Et là où ça devient sympathique, c’est qu’on peut réaliser tout un tas d’opérations en groupant ces registres logiques. Vous réalisez une multiplication, ce sont 32 valeurs multipliées d’un coup par 32 autres. Ça va 32 fois plus vite que faire la même opération de façon atomique.

Et là je reviens sur la programmation multi-coeur. Imaginez maintenant que vous avez un processeur à 16 coeurs qui exécute de l’AVX-512 en 16 bits. Vous avez multiplié la vitesse de traitement par 512. Alors aujourd’hui les cartes graphiques vont encore plus loin et permettent de paralléliser des opérations sur 2000 voir 3000 valeurs pour les cartes les plus puissantes. La puissance de calcul disponible dans nos ordinateurs et même un simple téléphone est aujourd’hui vraiment titanesque! Raison de plus de s’énerver quand votre système d’exploitation peine à ouvrir une simple fenêtre pour afficher une pauvre page web… ça donne peut-être une idée de tous les calculs qu’il est en train de réaliser afin de voler vos données personnelles. Utilisez Linux.

Ce n’est pas un hasard si Microsoft a très longtemps utilisé Linux pour ses propres serveurs. Ah on s’est moqué d’eux longtemps, n’empêche qu’ils ont continué à utiliser Linux longtemps. Ce n’est que récemment qu’une partie de leurs serveurs utilise enfin Windows Server. LOL! Windows Server existe depuis 30 ans, c’était NT au début. Sauf que l’OS était incapable de rester actif plus de quelques semaines. Il plantait systématiquement à cause d’une histoire d’horloge qui repassait à zéro. Ceci explique la crainte des clients lors du passage à l’an 2000. À côté de ça, les serveurs Unix avait coutûme de rester allumés des années. Les redémarrages étaient rarissimes. Je me souviens qu’un serveur du site Fnac.com n’avait pas été redémarré depuis 2 ans et la production se demandait si tout se passerait bien au redémarrage.

Ah, on savait que la machine allait redémarrer. Ce qu’on ne savait pas, c’est si le script de démarrage contenait bien tous les programmes à lancer pour faire fonctionner la production. Il était probable que certains outils aient été lancé à la main deux ans auparavant et qu’il faudrait faire de même… Tu te rappelles toi y a deux ans? Heu… non. D’où l’importance de noter les choses et les réaliser rapidement. On n’était pas sur le même genre de problématiques que Windows, c’était fiable et robuste. Il ne manquait rien à Linux, à part les jeux vidéos…

C’était sans compter sur Steam et l’attrait grandissant des éditeurs!

Mais ceci est une autre histoire…

Chiptune: Are You Gerpy? by Bartesek / Casyopea

Agenda

Travailleurs du clic : l’envers invisible de la modération, échanges avec Antonio Casilli

Antonio Casilli, sociologue et expert reconnu du digital labour, partagera ses travaux sur cette face cachée du numérique et la réalité du métier de modérateur de contenus.

Sur inscription ;
3 février 2026, de 12h30 à 13h30 ;
En ligne.

Décrypt’innov #2 : L’IA non générative

rendez-vous mensuel pour décrypter les tendances de l’innovation.

• Objectif : Vous repartez avec quelque chose que vous avez réellement compris.
• Méthodo : On part des idées reçues → on clarifie → on échange et on comprend.
• Thématique de cette édition : L’IA non générative.

Sur inscription ;
Vendredi 6 février, de 13h à 14h ;
Le Moulin Digital – Espace de coworking & conseil numérique, Alixan.

AmigaBouffe

Première AmigaBouffe de 2026 pour TripleA. Venez avec votre ordinosaure ! Cette réunion se terminera par un repas.

Payant, sur inscription ;
Samedi 7 février, à partir de 14h ;
Salle des fetes de Clérieux.

Du lien et des liens

Plusieurs listes collaboratives d’API publiques pour développeurs.

De quoi jouer aussi :

Une mise à jour de l’émulateur PCSX2 ouvre l’accès à 99,5% du catalogue de la PlayStation 2 sur ordinateur. Cette solution, légale sous conditions, permet de rejouer à ses classiques avec des graphismes améliorés.

Free in the Dark, un portage GPL2 de Alone in the Dark 1, 2 et 3.

SupraPacman, un plugin pour jouer à Pacman dans l’éditeur Vim. Ne vous plaignez pas ensuite de devoir consulter le docteur dans Emacs !

Astrologeek

• oldschool : AIX c’est l’ex-Unix d’IBM. – Ah ils ont divorcé ?
• technocritique : (chanson Déjeuner en paix) J’abandonne sur une chaise ce DVD coquin, les platines le refusent d’où qu’elles viennent. J’attend qu’elles se réveillent et qu’elles le lisent enfin, je souffle sur la poussière d’la lentille… Ce soir je ne les reflasheraient pas, le firmware est à jour; Je cass’rai moi-même ce vilain DRM… C’est pour quoi, je voudrais, enfin si vous permettez… dézonner en paix… dézonner en paix…
• nerd : Les lasagnes sont devenues le type de pâtes dominant dans les années 1980 car… on pouvait les faxer.
• demomaker : Excusez-moi pour ce roto-zoom, j’ai mangé trop de pixels.
• procrastinateur : Mieux que le mode sombre, le mode sombrero.
• vibe-codeur : C’est vraiment un contenu slop-horrifique.