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 , par Michael Guilloux

230PARTAGES

10  0 
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?

Que pensez vous de l'avertissement de Jon Corbet ?

Quelles seraient les conséquences du bug 2038 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 23/02/2015 à 13:49
Je 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.
11  1 
Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 23/02/2015 à 16:15
c'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....
9  0 
Avatar de Jedai
Expert éminent https://www.developpez.com
Le 02/03/2015 à 11:13
Il 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)
9  0 
Avatar de bilgetz
Membre averti https://www.developpez.com
Le 23/02/2015 à 15:13
Citation Envoyé par fenkys Voir le message

Personnellement, je pense que la plupart des système embarqué 8, 16 et 32 bits, aujourd'hui seront certainement hors d'usage d'ici 2038. 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é.
C'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.
8  0 
Avatar de DAUDET78
Membre éprouvé https://www.developpez.com
Le 01/03/2015 à 23:19
Citation Envoyé par Uther Voir le message
On peut tout à fait gérer ses dates sur 64 bit même avec une machine 32 bits,.......
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 ?
8  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 23/02/2015 à 15:47
Citation Envoyé par sazearte Voir le message
Sa provoquerait quel bug exactement ? le système croira que l'on est en 1970 (pas très grave je pense dans 90% des appareils) ou bien on aura un kernel panic ?
Ç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.

Citation Envoyé par cuicui78 Voir le message
il y a une multitude de secteur on ça pose portable de ce croire en 1900. les secteurs financiers par exemple
Citation Envoyé par yahiko Voir le message
Sauf que la prévalence de Linux dans le domaine financier pur, je suis très sceptique.
Et dans ce domaine, éloigné du matériel, une migration des applications vers du 64 bits résout simplement le souci.
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.

Citation Envoyé par fenkys Voir le message
C'est une erreur dans la traduction ou l'auteur a réellement parlé de Linux. Parce que c'est un problème lié à Unix en général est pas juste à Linux.
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.

Citation Envoyé par fenkys Voir le message
Personnellement, je pense que la plupart des système embarqué 8, 16 et 32 bits, aujourd'hui seront certainement hors d'usage d'ici 2038. 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é.
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.
7  0 
Avatar de temoanatini
Membre averti https://www.developpez.com
Le 23/02/2015 à 14:34
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é
Bon nombre de programmes doivent gérer des dates "dans le futur". Il faut bien être capable de pouvoir entrer ces dates.
6  0 
Avatar de DAUDET78
Membre éprouvé https://www.developpez.com
Le 26/02/2015 à 23:15
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

Daudet
6  0 
Avatar de DAUDET78
Membre éprouvé https://www.developpez.com
Le 27/02/2015 à 9:35
Citation Envoyé par sazearte Voir le message
c'est pas cela qui va empecher Mr Dupont de démarrer sa voiture
pas évident ! Si il y a un contrôle des dates de vidanges.......
ou son lecteur Bluray (enfin je l'espère)
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 .
6  0 
Avatar de Michel Merlin
Inactif https://www.developpez.com
Le 27/02/2015 à 15:02
y2038 = y2k = big buzz, tiny problem

A - En 1992 j'ai eu à refaire le système de gestion du temps dans la grande application de notre Lab, qui fonctionnait chez nos clients sur toutes les versions d'UNIX (de mémoire SunOS, HPUX, AIX, et les autres dont j'ai oublié les noms de DEC, SGI, etc). Je me suis vite aperçu que c'était IMPOSSIBLE de trouver pour cela des outils logiques, cohérents, FIABLES, dans UNIX. Pourtant j'ai épluché la doc : celle d'UNE station UNIX de Sun faisait 1.5 mètres de livres A4, chacun ~1000 pages remplies en petits caractères, extrêmement verbeux, peu précis, peu logique, sans renvois efficaces donc tout est à chercher par soi-même, ce que j'ai fait mais cela m'a fait comprendre pourquoi les développeurs (une 30aine de jeunes thésards étrangers encadrés par 5 ou 6 spécialistes) y avaient renoncé et ignoraient en fait UNIX sur lequel ils travaillaient pourtant tous les jours depuis des années.

J'ai donc refait un nouveau système Temps, entier en partant de zéro (depuis l'étude de l'histoire du calendrier) ; le stockage et le traitement du temps étaient tout entiers dans l'application, seuls y étaient propres aux machines et OS de nos clients les fonctions genre DATE et TIME pour accéder à leur horloge matérielle, que je convertissais immédiatement conformément aux formats définis dans mon module Temps. Lequel, comme certainement l'écrasante majorité de ceux faits sur la planète, était fait sérieusement et consciencieusement, donc bien sûr traitait correctement les transitions des années Zéro (les Historiens n'ont pas d'année Zéro comme les astronomes) et 1582 (Julien-Grégorien), et encore plus évidemment les années bissextiles et les changements de siècles (y compris les exceptions genre 1700, 1800, 1900, 2100, etc) ou de millénaires (Ans Zéro, 1000, 2000, etc).

B - Vers 1997 a commencé le buzz, incroyable pour un programmeur consciencieux, à propos de la "catastrophe" annoncée du "Bug de l'An 2000" : on a presque cherché si Nostradamus l'avait prédit ! Stupéfait qu'une pareille peur moyenâgeuse et irréfléchie puisse prendre une telle ampleur dans les médias j'ai aussitôt écrit publiquement sur divers forums que l'An 2000 ne causerait aucun problème sur les programmes sérieux, sans doute encore l'écrasante majorité à l'époque, où il n'était qu'un cas particulier de cas particuliers déjà forcément largement traités.

C- La nuit du Fri 31 Dec 1999 au Sat 01 Jan 2000 j'avais à l'avance préparé des stations de travail (SunOS, HPUX, AIX) et PCs au Lab et chez moi, pour qu'ils soient tous en marche et connectés au moment fatidique, y compris retour momentané du vieux PC prêté à un fils étudiant. Comme prévu les problèmes ont été absolument inexistants sur les stations UNIX tournant mon programme, mineurs et vite contournés sur les PCs Windows (et IIRC sur les Macs du Lab), mais graves et irréparables sur... 3 stations UNIX du Labo qui n'utilisaient pas notre programme (des haut-de-gamme du service mécanique qui tournaient Matra Euclide au lieu de notre grande appli, généraliste Éléments Finis mais plus orientée Génie Civil). Ces 3 luxueuses stations ont dû recevoir en catastrophe dans les 3 semaines le remplacement normalement prévu plus tard : il est impossible de gérer correctement une grande quantité de projets avec une horloge fausse.

D - Les jours suivants il est apparu que notre Lab reflétait bien la situation mondiale d'ensemble : l'An Y2K n'avait causé aucun problème en général, les seules exceptions étaient rares et ne concernaient que certains systèmes UNIX : le "Y2K" était immédiatement et complètement dégonflé.

E - Pour y2038 je m'attends à la même chose : AVANT l'échéance, un énorme buzz de la part de ceux qui n'ont pas les moyens de réfléchir avant d'écrire (notamment dans le journalisme, où une condition sine qua non du succès est de NE JAMAIS réfléchir ou vérifier, sinon votre papier arrive après le bouclage) ; APRÈS l'échéance, un impact encore plus négligeable qu'en Y2K. Raisons :

- Il faut être particulièrement non-concerné (ce qui peut arriver) ou négligent pour avoir encore en 2015 un système ne traitant pas correctement le temps au delà de 2038 ; la plupart des programmes auront bien dans les 23 ans qui viennent au moins UN programmeur consciencieux, qui y remédiera, surtout si le buzz continue (je suis donc obligé de lui reconnaître une utilité, même marginale).

- Pour que CETTE erreur se produise il faut avoir stocké le temps TOTAL (DATE *et* TIME) en SECONDES ENTIÈRES sur UNE SEULE variable ENTIÈRE (32 bits), ce qui peut donc aller jusqu'à 2^31 = 2,147,483,648 secondes, soit le temps entre l'origine UNIX (01 Jan 1970 0h GMT) et comme dit l'article Tue 19 Jan 2038 03:14:07 GMT (donc le bug se déclarerait à 03:14:08 GMT). Mais faire un tel stockage, PIRE que ceux des variantes d'UNIX et des plus bâclées des applis développées dessus, ç'aurait déjà été difficile à imaginer en 1997, ce serait inqualifiable en 2015. Il y a donc tout lieu de croire que c'est une hypothèse la plus pessimiste possible de journaliste ou de forumiste, et non pas une constatation par des personnes informées sur des programmes réellement existants.

- Subordonner la solution (stocker correctement chaque date sur 64 bits) au passage de tout l'OS à 64 bits, c'est écraser une mouche avec un marteau-pilon, on peut difficilement l'imaginer ailleurs que chez les journalistes et "experts" ministériels ; comme le montre (parmi des millions d'autres) mon exemple, il est très facile et économique de le faire, avec une haute fiabilité, sur un système entièrement 32 bits (OS, langage, appli).

Versailles, Fri 27 Feb 2015 15:02:00 +0100, édité (2 typos, +1-3 car) Mon 02 Mar 01:29:00 +0100
6  1 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web