Unix : l’apocalypse n’aura finalement pas lieu en 2038 pour les systèmes en 32 bits

Le 19 janvier 2038 (c’est un mardi), le monde s’achèvera à 3 heures 14 minutes et 8 secondes. Non, il ne s’agit pas d’une prédiction issue d’un livre Saint mais bien d’une affirmation. Ce qui va se passer, c’est qu’à partir de ce moment, la valeur du temps dans les systèmes d’exploitation Unix basés sur 32 bits – comme Linux et les anciennes versions de macOS – sera à court de chiffres et commencera à décompter le temps avec des chiffres négatifs.

On peut s’attendre à ce que les ordinateurs 32 bits fonctionnant avec ces systèmes d’exploitation souffrent alors de différents ajustements. Fort heureusement, les développeurs de Linux ont d’ores et déjà la parade en publiant un correctif prêt à l’emploi.

Le problème commence avec la façon dont Unix donne l’heure. Cette famille de systèmes d’exploitation – qui comprend notamment Linux, macOS ainsi que d’autres systèmes d’exploitation compatibles POSIX – date le début de l’ère, c’est-à-dire 00:00:00 GMT le 1er janvier 1970. Ce qui revient à dire que la famille Unix mesure le temps par le nombre de secondes écoulées depuis l’époque.

Des mesures de précaution s’imposent

Cette famille ayant commencé en tant que systèmes d’exploitation 32 bits, la valeur du temps est conservée sous la forme d’un nombre entier unique signé sur 32 bits. Cela représente un grand nombre de secondes, même si celui-ci n’est pas illimité. Reste que les développeurs de Linux en sont conscients depuis longtemps et ne sont pas restés inactifs face au problème. C’est ainsi que le développeur du noyau Linux Arnd Bergmann et d’autres ont travaillé sur une réparation. Des corrections sont maintenant disponibles dans le prochain noyau Linux 5.6.

“Linux-5.6, ou mon rétro-portage des correctifs de la 5.4, devrait être la première version pouvant servir de base à un système 32 bits conçu pour fonctionner au-delà de l’année 2038”, a ainsi fait savoir le développeur. Non sans adresser quelques mises en garde :

• Tout l’espace utilisateur doit être compilé avec un time_t 64 bits, qui sera pris en charge dans les prochaines versions musl-1.2 et glibc-2.32, ainsi que les en-têtes de noyau installés à partir de Linux-5.6 ou supérieur.
• Les applications qui utilisent directement les interfaces d’appel système doivent être portées pour utiliser les appels système time64 ajoutés dans Linux-5.1 à la place des appels système existants.
• Les applications qui utilisent une copie privée des fichiers d’en-tête uapi du noyau ou de leur contenu peuvent avoir besoin d’une mise à jour vers la version Linux-5.6.
• Quelques interfaces restantes ne peuvent pas être modifiées pour passer un time_t de 64 bits de manière compatible, elles doivent donc être configurées pour utiliser les temps CLOCK_MONOTONIC.
• Tous les problèmes Epoch présents sur les machines 64 bits s’appliquent également aux machines 32 bits. Cela affecte en particulier les systèmes de fichiers avec des horodatages sur disque utilisant des secondes signées en 32 bits : ext4 avec des petits inodes de type ext3, ext2, xfs (à corriger bientôt) et ufs.

La famille Unix invulnérable ?

Maintenant, vous vous demandez peut-être – puisque nous utilisons tous des ordinateurs 64 bits de nos jours – pourquoi cela pose problème. Eh bien, c’est comme ça. Tout d’abord, de nombreux systèmes embarqués et appareils de l’Internet des objets fonctionnent encore avec des systèmes d’exploitation 32 bits. En effet, d’ici 2038, il y aura probablement encore de nouveaux appareils 32 bits arrivant sur le marché.

Nous savons également, depuis le fameux “bug de l’an 2000” qui réapparaîtra en 2020, que les systèmes dont on peut penser qu’ils seront mis en décharge dans 18 ans seront toujours en vie et se porteront bien.

Vous pouvez aussi regarder le verre à moitié plein. Une fois que nous aurons réglé ce problème, nous n’aurons plus à nous soucier du fait que le système Linux 64 bits ne sera plus disponible avant 15h30 et 8 secondes GMT le dimanche 4 décembre 29 227 702 659. Une bonne chose de faite.

Source : ZDNet.com