Le «bug de l'an 2000» se reproduira en 2038 dans le monde Linux
Mais c'est maintenant qu'il faut s'inquiéter selon Jon Corbet
Le 2015-02-23 13:06:07, par Michael Guilloux, Chroniqueur Actualités
Jon Corbet, chroniqueur de longue date du noyau Linux a exprimé son inquiétude par rapport à une menace imminente qui pourrait affecter les systèmes Linux et autres systèmes compatibles avec Unix en 2038.
Le problème est similaire au bug Y2k ou bug de l'an 2000 qui a affecté les systèmes fonctionnant sur 2 digits. En effet, avant l'an 2000, plusieurs programmes informatiques enregistraient les années sur 2 chiffres à partir de 1900, ce qui donnait par exemple 80 pour 1980. Le problème qui est survenu en 2000 est que les programmes ne pouvaient plus distinguer par exemple l'année 1900 de l'année 2000, puisque les 2 années avaient le même code, soit 00. Ce bug a eu de nombreuses conséquences étant donné que tous les systèmes informatiques s'appuient fortement sur les horloges pour faire marcher presque toutes les fonctions.
En ce qui concerne le système Linux et les systèmes compatibles avec Unix, les codes temporels "time_t" stockent la date et l'heure comme un entier signé de 32 bits représentant le nombre de secondes depuis le 1er Janvier 1970 (00:00:00 1970). A partir de 2038, plus exactement le 19 Janvier 2038 à 3:14:07 GMT, il n' y aura plus assez de bits pour stocker les dates allant au-delà, d'où un nouveau bug de l'an 2038 pour le monde Linux. Cela affectera tous les systèmes Linux 32 bits.
Vous direz peut-être que ce n'est pas un problème en soit, puisque d'ici là, de nombreux systèmes seront tournés vers un horodatage 64 bits. Mais le problème est que rien ne prouve que les systèmes 32 bits seront abandonnées, la preuve en est qu’aujourd'hui, beaucoup de systèmes embarqués utilisent encore des processeurs 16 bits ou même 8 bits et un grand nombre de systèmes dits embarqués utilisent Linux 32 bits. En plus, ces systèmes sont rarement remplacés une fois qu'ils sont installés.
Jon Corbet, voyant la menace s'approcher à grands pas, a déclaré lors du récent sommet de collaboration de la fondation Linux à Santa Rosa en Californie, qu’ « il est temps de commencer à s'inquiéter.»
« Les systèmes basés sur Linux sont implémentés dans des voitures, dans la construction de systèmes de contrôle, dans les centrales électriques, et dans, qui sait combien, plusieurs autres endroits où ils y seront tout simplement placer et feront leur travail jusqu'à ce time_t vienne à manquer de bits. Et alors ils ne fonctionneront plus. » A-t-il déclaré.
Il pense que les développeurs devraient songer à arrêter les expéditions de logiciels avec ce problème et commencer à travailler sur la manière d'éviter la menace avant qu'elle ne nous surprenne car les conséquences seront graves.
« Si nous continuons à distribuer des logiciels qui ont ce problème en eux, nous mettons en place des problèmes pour l'avenir, et nous ne voulons pas faire cela», a déclaré Corbet. « Le temps de le réparer, c'est maintenant », a-t-il ajouté.
Source : Kit Guru
Et vous?
Le problème est similaire au bug Y2k ou bug de l'an 2000 qui a affecté les systèmes fonctionnant sur 2 digits. En effet, avant l'an 2000, plusieurs programmes informatiques enregistraient les années sur 2 chiffres à partir de 1900, ce qui donnait par exemple 80 pour 1980. Le problème qui est survenu en 2000 est que les programmes ne pouvaient plus distinguer par exemple l'année 1900 de l'année 2000, puisque les 2 années avaient le même code, soit 00. Ce bug a eu de nombreuses conséquences étant donné que tous les systèmes informatiques s'appuient fortement sur les horloges pour faire marcher presque toutes les fonctions.
En ce qui concerne le système Linux et les systèmes compatibles avec Unix, les codes temporels "time_t" stockent la date et l'heure comme un entier signé de 32 bits représentant le nombre de secondes depuis le 1er Janvier 1970 (00:00:00 1970). A partir de 2038, plus exactement le 19 Janvier 2038 à 3:14:07 GMT, il n' y aura plus assez de bits pour stocker les dates allant au-delà, d'où un nouveau bug de l'an 2038 pour le monde Linux. Cela affectera tous les systèmes Linux 32 bits.
Vous direz peut-être que ce n'est pas un problème en soit, puisque d'ici là, de nombreux systèmes seront tournés vers un horodatage 64 bits. Mais le problème est que rien ne prouve que les systèmes 32 bits seront abandonnées, la preuve en est qu’aujourd'hui, beaucoup de systèmes embarqués utilisent encore des processeurs 16 bits ou même 8 bits et un grand nombre de systèmes dits embarqués utilisent Linux 32 bits. En plus, ces systèmes sont rarement remplacés une fois qu'ils sont installés.
Jon Corbet, voyant la menace s'approcher à grands pas, a déclaré lors du récent sommet de collaboration de la fondation Linux à Santa Rosa en Californie, qu’ « il est temps de commencer à s'inquiéter.»
« Les systèmes basés sur Linux sont implémentés dans des voitures, dans la construction de systèmes de contrôle, dans les centrales électriques, et dans, qui sait combien, plusieurs autres endroits où ils y seront tout simplement placer et feront leur travail jusqu'à ce time_t vienne à manquer de bits. Et alors ils ne fonctionneront plus. » A-t-il déclaré.
Il pense que les développeurs devraient songer à arrêter les expéditions de logiciels avec ce problème et commencer à travailler sur la manière d'éviter la menace avant qu'elle ne nous surprenne car les conséquences seront graves.
« Si nous continuons à distribuer des logiciels qui ont ce problème en eux, nous mettons en place des problèmes pour l'avenir, et nous ne voulons pas faire cela», a déclaré Corbet. « Le temps de le réparer, c'est maintenant », a-t-il ajouté.
Source : Kit Guru
Et vous?
-
yahikoRédacteur/ModérateurJe suis sûr que de nombreuses SSII seront d'accord pour dire qu'il s'agit là d'un problème extrêmement préoccupant.le 23/02/2015 à 13:49
-
bilgetzMembre avertiC'est ce que se disait les développeur dans les années 80 et on vu le résultat.
Il reste en gros 20 ans.
Certain logiciel dure facilement 20 ans ( faut voir les administrations et les banques).
Une voiture çà se garde 20 ans et il y a de plus en plus d’électronique a l’intérieur.
En prenant des mesure maintenant, cela coutera moins d'argent que de le faire plus tard.le 23/02/2015 à 15:13 -
AiekickMembre extrêmement actifc'est ballot pour la sonde voyager 1. Quand les extraterrestre tomberont dessus, il penseront qu'elle vient d'a coté faisant des boucles de 136 ans....le 23/02/2015 à 16:15
-
JedaiExpert éminentIl est remarquable que cette discussion s'étale sur 3 pages sans que personne ne soit allé voir l'état des discussions des développeurs du noyau sur le sujet... Cela semble une première étape nécessaire si l'on souhaite être constructif dans sa critique du problème.
En particulier une décision a finalement été adapté, résumée dans la seconde partie de cet article : http://lwn.net/Articles/599580/.
Je traduis pour les anglophobes : après avoir enfin pris la peine de discuter avec les développeurs des libc, en particulier la glibc, les développeurs du noyau ont décidé de créer un certain nombre de nouveaux appels systèmes "version 64 bits" comme gettimeofday64() qui fonctionne avec un nombre de secondes en 64 bits. La glibc pourra être compilé avec l'option TIME_BITS=64 pour que les appels classiques comme gettimeofday() soit redirigés vers leur version 64 bits, même sur des système 32 bits (ou moins) et cette option deviendra standard dans les distributions lorsque la situation se sera stabilisée.
Ceci a été mis en place dans le dernier noyau stable (le 3.19 au moment où je parle).
Le problème de l'année 2038 est donc bien anticipé et les problèmes ne devraient exister que dans des systèmes embarqués jamais mis à jour ou des applications développées avec les pieds.
(La plupart des BSDs, moins préoccupés par la compatibilité binaire et habitués à changer l'ABI ont simplement décidé que leurs systèmes utiliseraient tous un time_t en 64 bits, quelque soit l'architecture)le 02/03/2015 à 11:13 -
DAUDET78Membre éprouvéC'est là tout le problème ..... On peut, mais est ce qu'on le fait en 2015 pour des programmes qui risquent d'être encore en service en 2038 ?le 01/03/2015 à 23:19
-
temoanatiniMembre avertiBon nombre de programmes doivent gérer des dates "dans le futur". Il faut bien être capable de pouvoir entrer ces dates.Se préoccuper de cela maintenant alors qu'on ne sait exactement quels seront les systèmes ayant survécu à cette date future me semble un peu prématuréle 23/02/2015 à 14:34
-
UtherExpert éminent séniorÇa dépendra totalement des applications. Un plantage n'est pas a exclure, mais pour les applis qui se fichent de la date, il est en effet probable que ça n'aura aucun effet.
Les secteurs financiers sont bien au courant du problème et ont l'habitude de travailler avec des dates notamment dans le futur. Je ne me fait pas trop de soucis pour eux.
Les financier utilisent beaucoup de serveurs Unix/Linux, mais ça fait un moment qu'ils ont pris l'habitude de travailler avec des date de 64 bit.
C'est un abus de langage, de nos jour plus de 90% de ce qu'on appelle des Unix sont des Linux, même si ça ferra raller les puriste qui rappelleront que Linux n'est pas UNIX. Bref on va pas chipoter, il y a de toute façon aussi des application Windows qui utilisent le format de date UNIX et qui seront donc concernées aussi.
Bien sur il serait complètement idiot de rendre des a présent compatible des application qui auront certainement disparu en 2038, ce n'est pas du tout ce que le monsieur propose. Il dit juste que ça ne coute presque rien de s'en préoccuper maintenant pour les nouvelles applications et permettra de faire des économies à l'avenir, donc autant le faire.le 23/02/2015 à 15:47 -
DAUDET78Membre éprouvéBonsoir,
Perso, à 72 ans, je ne me sens plus concerné par ce BUG ..... mais je rigole d'avance !
Bof, 23 ans , on a le temps de voir venir, pourquoi s'en préoccuper maintenant ?
En 1990, on a fait la même chose pour le BUG de l'an 2000. Bof, on a le temps ! Et en 1998, on s'est aperçu qu'il y avait encore des paquets de logiciel en Fortran, Cobol ou autres qui étaient encore en service. Manque de bol, les spécialistes étaient à la retraite !
Et on va continuer à jouer avec le feu en produisant des logiciels tournants sous Linux ou Unix qui se planteront joyeusement en 2038 !
Vive les apprentis sorciers
Daudetle 26/02/2015 à 23:15 -
DAUDET78Membre éprouvépas évident ! Si il y a un contrôle des dates de vidanges.......Celui là sera mourru avant la date fatidique ! A condition que ce ne soit pas un modèle acheté en 2033 sans correctif de date obsolète .ou son lecteur Bluray (enfin je l'espère)le 27/02/2015 à 9:35
-
23JFKMembre expertIl y a une pile nucléaire dans la sonde, si des extra-terrestres sont assez fûtés pour avoir maîtrisé les voyages interstellaires, il ne devraient pas avoir trop de difficultés à mesurer le rapport entre les différents isotopes et leurs composés filles pour en déduire le temps qu'aura passé cette boîte de conserve tunée dans l'espace.le 23/02/2015 à 16:51