Actus

p. 06  Côté livres

Hack

p. 08  Open Watcom : et si on développait pour DOS ?

Dossier : Spécial C++20 !

p. 21  Introduction au dossier
p. 22  C++20 : évolutions du langage
p. 34  Concepts en pratique
p. 48  C++20 : la librairie std::ranges
p. 58  C++20 : la librairie std::format
p. 72  C++20 : évolutions de la STL
p. 94  C++20 : évolutions sur le parallélisme

Repères

p. 110  Reconstruire son FreeBSD pour une plateforme non supportée par la distribution binaire  

80486, le début de la fin.

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

Le questionnement est parfaitement légitime, le temps à disposition des développeurs n’est pas infini, il ne l’est pour personne malheureusement, et supporter des architectures que quasiment plus personne n’utilise n’a pas vraiment d’intérêt, si ce n’est ludique. Oui, voir tourner un Linux 6.0 sur un 486, ou un FreeBSD 13.1 sur un Pentium est amusant, mais quiconque l’aura fait se sera rendu compte qu’au-delà du plaisir de l’exercice en lui-même, il n’y a pas grand intérêt (sauf peut-être dans l’exercice de la patience).

La suggestion de Linus d’abandonner le support 486, comme cela a été fait il y a dix ans pour le 386, a provoqué quelques commentaires, généralement liés à la sécurité, puisque plus personne ne s’occupe de ces morceaux de code. Il faut cependant faire attention, car les raccourcis sont aisés et les généralisations malheureuses trop fréquentes. Exemple :

« Microsoft est dans son bon droit de rejeter les ordinateurs dépourvus du TPM 2.0, menaçant la sécurité des utilisateurs et de l’Internet. »

Non seulement il y a tout un monde entre l’abandon d’un type de CPU obsolète depuis des années et le fait d’imposer une fonctionnalité matérielle, mais surtout, il convient de ne pas confondre sécurité et réduction arbitraire de périmètre. Ce qui menace la sécurité, ce n’est pas la diversité du matériel supporté, mais bel et bien la qualité du code et la présence de vulnérabilités. L’imposition de choses comme un TPM ou des restrictions de support matériel n’empêcheront pas les problèmes comme ceux auxquels ont fait face les utilisateurs et projets reposant sur Log4j, par exemple.

Oui, réduire la surface d’attaque est une bonne chose, mais non, ce n’est pas et ce ne sera jamais une solution miraculeuse, sauf peut-être pour enfermer l’utilisateur crédule dans une prison de verre pour sa propre sécurité...

Denis Bodor