Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 23JFK
Membre expérimenté https://www.developpez.com
Le 23/02/2015 à 16:51
Citation Envoyé par MikeRowSoft Voir le message
C'est vrai ? Ils n'ont rien pris comme horloge style chronomètre avec positionnement stellaire initiale pour comparer les l'instants du départ à sa découverte ?
Je suis vraiment intrigué. Pourvu que les déplacements périodiques de l'univers ne leurs soient pas une source d'imprécision, surtout lorsque les galaxies se rencontre.
Il 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.
5  0