En 2000, le bogue de l’an 2000 est venu et est passé sans beaucoup de problèmes. Malgré les prédictions d’une défaillance généralisée, la crise a été évitée par une planification et une intervention à la fois à long terme et de dernière minute, et aucun système critique n’est tombé en panne. Dans les années qui ont suivi, les quelques systèmes d’exploitation et applications qui ont été affectés ont, dans la plupart des cas, été mis à niveau, remplacés ou retirés.
Si vous utilisez un système basé sur Unix ou Linux, il y a un autre bogue lié à la date dont vous devrez vous inquiéter — en 2038.
Tous les systèmes 32 bits basés sur Unix/Linux stockent l’heure de l’horloge système en interne comme le nombre de secondes depuis l’époque, ou 00:00:00 le 1er janvier 1970. Ce type de données interne, time_t, est dans la plupart des cas un entier signé de 32 bits (4 octets). Si le système en question suit la norme POSIX (comme la plupart des systèmes Unix et Linux), l’heure et la date les plus tardives qui peuvent être représentées comme des secondes depuis l’époque dans cet entier signé de 32 bits est 3:14:07 UTC le mardi 19 janvier 2038.
Après cette heure et cette date, la représentation interne de l’heure du système atteindra 2147483647, le nombre le plus élevé stockable dans un entier signé de 32 bits. Une seconde plus tard, elle se transformera en un nombre négatif, -2147483648. Les applications actuelles vont soit interpréter ce nombre négatif comme une année plus ancienne (1901), soit figer l’horloge du système à 03:14:07 le 19 janvier 2038. Cela pourra éventuellement faire échouer les applications et les systèmes d’exploitation, car ils ne sont pas conçus pour fonctionner avec une horloge système bloquée ou une horloge indiquant l’année 1901.
Il n’existe pas de correctifs viables (qui ne cassent pas les applications existantes) pour les systèmes utilisant des processeurs 32 bits, ou les systèmes d’exploitation et les applications fonctionnant en mode 32 bits sur des processeurs 64 bits. De nombreux systèmes d’exploitation Unix/Linux actuels fonctionnent déjà en mode 64 bits (avec un time_t « long » correspondant lorsque sur un processeur 64 bits ; dans la plupart des cas, cela résout le problème.
Les systèmes d’exploitation qui prennent en charge un time_t 64 bits long ne sont très probablement pas affectés par le bogue de l’an 2038 en termes d’horloge système interne. Cependant, les applications qui utilisent un time_t 32 bits peuvent toujours échouer, même si le système qui exécute l’application prend en charge un fonctionnement 64 bits complet.
Voici un aperçu rapide de l’état actuel du support Unix 2038 dans les versions Unix/Linux grand public :
- Solaris 7 ou plus sur les processeurs 64 bits UltraSPARC et SPARC64, ainsi que Solaris 10 sur les plates-formes x86-64, possède un time_t 64 bits.
- La version 4.3.3 d’AIX sur les processeurs PowerPC et Power 64 bits possède un time_t 64 bits.
- Le noyau Linux fonctionnant en mode 64 bits sur les processeurs IA64 ou x86-64 possède un time_t 64 bits.
- Mac OS X version 10.4 et plus récente a un noyau 32 bits, mais les applications peuvent utiliser un time_t 64 bits lorsqu’elles fonctionnent sur des processeurs PowerPC G5 ou x86-64.
- FreeBSD 6.0 et plus récent a un time_t 64 bits lorsqu’il fonctionne sur une plateforme 64 bits.
- OpenBSD 4.1 et plus récents supportent un time_t 64 bits.
- NetBSD n’a pas encore de time_t 64 bits, mais des efforts sont en cours pour corriger le problème pour une prochaine version.
Même si votre système d’exploitation actuel n’est pas encore sûr Unix 2038, ne vous inquiétez pas ! Les gens sont conscients du problème depuis de nombreuses années maintenant, et travaillent activement sur des solutions. Dans la plupart des cas, le problème sera résolu en faisant en sorte que le système d’exploitation et les applications finissent par fonctionner en mode 64 bits complet.
Je m’attends à ce que tous les principaux systèmes d’exploitation de bureau soient entièrement 64 bits dans les cinq à dix prochaines années. De plus, un effet de ruissellement aidera à remplacer les systèmes actuels par des configurations 64 bits lorsque cela est applicable et rentable.
À PROPOS DE L’AUTEUR : Bill Bradford est le créateur et le mainteneur de SunHELP et vit à Houston, au Texas, avec son épouse Amy.