Discussion :

[23JFK]

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.

[MikeRowSoft]

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.

Tu me rassure, ils finiront bien par nous retrouver. Malgré le manque de beaucoup de caractère aléatoire en fonction des masses et des gravités. Pourvu que se ne soit pas une invasion.

[captaindidou]

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.

quelle datation est possible ?
Ce n'est pas le tout de connaître la décroissance radioactive, Encore faut-il connaître la teneur en isotope radioactif au moment de l'envoi de la sonde.
Pour la datation au carbone 14, c'est différent : il s'agit d'un corps qui a été vivant et donc qui a interagit avec le milieu naturel conservant ainsi la même teneur en carbone 14 que son milieu naturel.

[ZeRedDiamond]

Après, il ne faut pas oublier que nous sommes en 2015 donc il reste 19 ans et je pense qu'ils ont largement le temps de corriger ce problème-là. De quel façon? je sais pas je ne suis pas développeur de distributions Linux

Il faut juste pas qu'ils oublient de corriger ce bug.

ZeRedDiamond

[troumad]

Ceci me fait penser à des endroits super sécurisés comme des centrales nucléaires où on trouve encore du matériel informatique des années 80 car ils ont été certifiés : il revient moins cher de continuer à maintenir ce matériel que de certifier du nouveau matériel.
Il arrive de trouver une salle de relais qui tiendrait maintenant sur une carte informatique. Ceci dit, l'espérance de vie de ces relais antiques est largement supérieure aux cartes électroniques. L'expérience le prouve.

J'espère donc que toutes les centrales construites depuis 20 ans (voir plus) ont prévu ce bug.

[yahiko]

Faudrait il encore que nos centrales soient pilotées par du Linux, ce qui reste à établir.

[Jedai]

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)

[yahiko]

Que le bug soit anticipé par les développeurs du noyau, encore heureux oserai-je dire...

Mais comme on le sait tous, le plus compliqué dans une migration, ce ne sont pas les développements futurs, mais le legacy.
D'où les pages écrites ici apparemment.

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

[23JFK]

C'est alarmiste de dire que de tels systèmes cesseront de fonctionner. Seul ceux qui se réfèrent à des calculs de dates seront sérieusement affectés, les autres reprendront leur comptage à partir de zéro, le registre carry flag des processeurs n'est que rarement utilisé comme une condition d'arrêt de tout un système.

[MikeRowSoft]

C'est alarmiste de dire que de tels systèmes cesseront de fonctionner. Seul ceux qui se réfèrent à des calculs de dates seront sérieusement affectés, les autres reprendront leur comptage à partir de zéro, le registre carry flag des processeurs n'est que rarement utilisé comme une condition d'arrêt de tout un système.

Le bogue était surtout la compréhension par le SGBD de l'information de la date fourni par le bios. 1900 ou 2000 ou 2100 ou 2200 ou 9900 etc. Je crois que les partitions de fichiers n'ont jamais eu se problème.

[Escapetiger]

C'est alarmiste de dire que de tels systèmes cesseront de fonctionner. Seul ceux qui se réfèrent à des calculs de dates seront sérieusement affectés, les autres reprendront leur comptage à partir de zéro, le registre carry flag des processeurs n'est que rarement utilisé comme une condition d'arrêt de tout un système.

Effectivement, mais je me souviens bien de la nuit du 31 décembre 1999 passée au bureau avec l' IT au quasi-grand complet, DSI en tête.

On se demandait déjà, si avec toutes les interconnexions applicatives, un seul système et/ou applicatif passé à travers les mailles du filet de la cartographie n'allait pas avoir des effets de bord et nous avons eu un "faux positif".

Merci à nos collègues australiens à l'époque qui ont bien détendu la situation en tant que précurseurs

[RyzenOC]

Tu me rassure, ils finiront bien par nous retrouver. Malgré le manque de beaucoup de caractère aléatoire en fonction des masses et des gravités. Pourvu que se ne soit pas une invasion.

A mon avis on aura trouver des extra-terrestre ou eux nous aurons trouver sans la sonde, il est plus probable de capter une onde radio que de voir une boite de conserve dans l'immensité de l'espace.

[Jarodd]

Mais le problème est que rien ne prouve que les systèmes 32 bits seront abandonnées

Rien ne dit qu'ils ne le seront pas.

De l'art de blablater sur des rumeurs et de faire craindre le pire sans réel fondement... Juste du FUD.

[captaindidou]

Cela n'aura aucun impact ou sinon marginal à mon sens car seul le système d'exploitation emploie cette implémentation comme représentation interne.
Les applicatifs d'aujourd'hui emploient une implémentation de la date indépendant du système : les bases de données, la norme XML, ...

Il suffira donc de sortir une révision majeure de Linux et les utilisateurs de mettre en redondance l'ancienne révision Linux et la nouvelle.
Si l'on est suspicieux, s'assurer que les données système n'ont pas d'impact sur le système redondé en vérifiant que les données sont identiques entre le système nominal et le redondant.
Cela fait, on bascule sur le nouveau système Linux.

On a encore 23 ans pour le faire.

Précaution particulière à prendre : le cas des systèmes de fichiers dont la datation reprend celle de Linux. Donc, il faudra avant toute chose migrer les systèmes de fichiers dans ces cas.

Des migrations comme celles-ci, il s'en fait tous les jours sur Terre.
C'est donc une procédure de routine.

[vertex.3F]

On a encore 23 ans pour le faire.

il reste 18 ans

Des migrations comme celles-ci, il s'en fait tous les jours sur Terre.
C'est donc une procédure de routine.

facile ! en 2038 j'appelle mon SAV pour un équipement grand-public acheté en 2025

(obsolescence programmée oblige) le SAV me répond tranquillement :

désolé Monsieur, vous avez acheté ce matériel il y a plus de 12 ans, il est doté d'un processeur 32 bits, hélas nous n'assurons le support que pendant les 10 années qui suivent sa fin de commercialisation, ni les pièces de rechange ni le logiciel ne sont disponibles désormais pour votre équipement

[Christophe]

Envoyé par captaindidou
On a encore 23 ans pour le faire.
il reste 18 ans

23-18=5 ans --> valeur du déterrage du post.

[vertex.3F]

"Aux âmes bien nées, la valeur n'attend point le nombre des années." (Pierre Corneille)

rdv en 2038 si le post existe encore

[Bktero]

J'appelle le SAV aussi pour les centrales nucléaires ? Ca se passe comment ? Il y un numéro vert ?

[DAUDET78]

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