Discussion :

[Michael Guilloux]

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

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 ?

[RyzenOC]

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.

Ça 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 ?

[yahiko]

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.

[Aiekick]

il y a une multitude de secteur on ça pose portable de ce croire en 1900. les secteurs financiers par exemple

[yahiko]

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.

[fenkys]

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.

Une petite précision, le passage de 2038 ne fera pas passer le système en 1970 mais plutot en 1902 (le time_t est signé pour pouvoir exprimer des dates antérieures à 1970).

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é.

[temoanatini]

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.

[AoCannaille]

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.

Pas forcément. sur certains projets où la gestion de la maitrise de la mémoire est à l'octet prêt (type avionique), chaque type est redéfini, et donc on nous interdisait le "int" et on nous imposait une analyse de bornes necessaires par variable et d'utiliser int8 , int16, int32, uint32 etc...
Donc changer d'architecture ne suffira pas. Pourtant au final on était assez éloigné des limites matérielles, par contre l’important était vraiment la maîtrise réelle et démontrable de la mémoire.

[yahiko]

Intéressant... Mais je te "rassure", les applis financières ne sont pas nécessairement programmées par des ingénieurs rigoureux, loin de là

[RyzenOC]

Une petite précision, le passage de 2038 ne fera pas passer le système en 1970 mais plutot en 1902

Mais je croyait que c'était impossible de mettre une date inférieure au 1 janvier 1970 ?

Enfin, quand j'étais étudiant je me suis essayée a mettre la date en 1960 sa n'a jamais marché

[Bktero]

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é.

Le problème n'est pas tant celui des systèmes déjà dans la nature (qui ne seront sans doute pas tous morts en 2038). Le problème est qu'il n'y a pas actuellement de solution déjà massivement acceptée (à ma connaissance) et qu'on continue donc à lâcher dans la nature des systèmes avec ce potentiel problème. Certes 23 ans ça parait long, mais c'est la durée de vie de nombreux systèmes embarqués. On pourrait imaginer une solution simple comme une modification du type time_t pour être une valeur sur 64 bits et non 32 bits mais cela impose de recompiler les programmes, les revalider, pour certains les recertifier, et les redéployer. Autrement dit, pour beaucoup de systèmes, c'est mission quasi-impossible. Il faut donc bien traiter à la source et arrêter de déployer des systèmes qui vont nous péter à la figure (ou à celle de nos enfants ^^).

Remarquez, je dis ça, mais je bosse sur un nouveau système embarqué dont le temps est codé sur 32 bits... Mais, bon, il ne devrait pas vivre 23 ans (j'espère !)

[bilgetz]

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.

[Michael Guilloux]

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.

Dans l'article

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 SYTEMES COMPATIBLES AVEC UNIX en 2038.

Une petite précision, le passage de 2038 ne fera pas passer le système en 1970 mais plutot en 1902 (le time_t est signé pour pouvoir exprimer des dates antérieures à 1970).

Dans l'article

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).

Avec time_t , on peut gérer une période totale de 2³² secondes, soit à peu près 136 années. La date la plus reculée est 13 décembre 1901, et la plus avancée est 19 janvier 2038.

Donc avec time_t, on peut passer à 1902 comme tu l'as dit. Mais je crois que l'intervalle de 136 années en centré en 1970 (1970 -136/2 = 1902 et 1970+136/2=2038).

Corrige moi si je me trompe car je ne suis pas expert en la matière.

Voir aussi: heure Unix , Year 2038

[fenkys]

Mais je croyait que c'était impossible de mettre une date inférieure au 1 janvier 1970 ?

Enfin, quand j'étais étudiant je me suis essayée a mettre la date en 1960 sa n'a jamais marché

Pourtant ça fait partie de la norme. Le time_t, dans un environnement 32 bits est un entier signé (pouvant exprimer des dates de 1902 à 2038).

[Chal92]

Le problème vient du langage C et non de Linux en particulier. Il existe le même soucis potentiel sous Windows...

Le soucis est que la manière de représenter le temps (qui a effectivement une origine POSIX) atteint ces limites sous sa représentation 32 bits en 2038...
Après effectivement si on utilise une représentation 64 bits, cela donne de la marge...

Mais le soucis n'est pas forcement du coté du code mais si ce format est utilisé dans une représentation "stocké".... Par exemple le format ZIP a (si je ne m'abuse) une structure utilisant ce type en 32 bits...
Je vous laisse imaginer l'impact que peut avoir un changement de structure dans un fichier binaire...

[Guikingone]

Migrer un majorité de système en 64 bits d'ici là est envisageable, risqué mais envisageable, cela prendra du temps, de l'argent et des ressourcs mais le défis en vaut la chandelle.

Bon nombre de services se basent sur du 32 bits et on été écrit par des ingénieurs pas franchement rigoureux, on en voit le résultat futur ...

[Uther]

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.

il y a une multitude de secteur on ça pose portable de ce croire en 1900. les secteurs financiers par exemple

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.

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.

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.

[LawArticle]

Comme d'habitude ils vont s'en préoccuper 6 mois avant et tout leur pétera à la gueule

[MikeRowSoft]

Comme c'est drôle. Il n'y a pas la taille et le format de l'information avant d'y accéder, même à base de "goto".

[Aiekick]

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....