Vous vous souvenez du bug de l’an 2000 ? C’était que du bonheur ! Ca a relancé le marche de l’informatique surtout pour les vieux barbus fan de Cobol et en fait, à la place de l’apocalypse numérique que les médias nous proposaient, il ne s’est quasiment rien passé…
On n’a pas eu de crash d’avion, de black out, d’explosion nuclaire ou de paralysie de tous les Microsoft Windows de la planète…
Déçu ?
Naaaan, faut pas car un nouveau bug apocalyptique va faire son apparition dans 30 ans ! C’est à dire en 2038. Ce bug affectera principalement les systèmes à base d’unix car ces derniers stockes le temps (date et heure) dans un entier signé de 32 bits (signed integer pour les connaisseurs) contenant le nombre de secondes écoulées depuis le 1er janvier 1970.
Et alors me direz vous ? Alors la limite de ces 32 bits, c’est à dire la date maximum qu’on peut atteindre avec ce format standard c’est le 19 Janvier 2038 à 3h14 (le matin).
Ca y est vous comprenez tout ? Après cette date, le temps va se planter et être représenté comme un nombre négatif ce qui aura pour conséquence de planter pas mal de programmes qui ne se croieront plus en 2038 mais en 1901 !
On connait ce problème car le bug de 2038 s’est en fait déjà produit en Mai 2006 lorsque les AOLServer (serveur open source d’AOL) ont crashés. Le logiciel avait été conçu pour que les requêtes lancées en base de données n’expirent « jamais » mais au lieu de fixer ce timeout à 0, il a été fixé à 1 milliard de secondes dans le futur. Et pas de bol, 1 milliard de secondes après le 12 Mai 2006 à 21h27 et 28sec ça tombe en 2038, et le sytème a alors calculé des timeout négatifs, ce qui l’a fait crashé.
Ce bug a aussi affecté le Rover Spirit, robot lancé en 2003 et arrivé en 2004 sur Mars, qui a planté (souvenez vous) et n’a plus répondu pendant plusieurs jours. Tous les détails sont ici.
Et pour vous prouvez que je ne fabule pas, tout est expliqué sur Wikipedia. Vous trouverez aussi plus d’infos ici, là, là, là ou encore là.
Evidement, on se doute que d’ici 2038 la plupart des machines auront été patchées ou conçues de telle façon qu’elles passeront sans souci cette date mais certains systèmes anciens ou embarqués conservés par des sociétés qui ne veulent ou ne peuvent les faire évoluer seront sans doute affectés.
Je pense notamment à des appareils se trouvant actuellement dans l’espace ou à des systèmes plus petits comme les controlleurs de feux rouges, des systèmes de navigation (genre balise argos ou autre) voir même des routeurs ou des outils de controles dans les oléoducs qui ne pourront pas être mis à jour. Il faudra alors les remplacer.
Si vous êtes programmeur, vous pouvez réagir ! Ouais !
Vous pouvez déjà commencer à auditer votre code en utilisant la FakeTime Preload Library et en lisant les recommandations de l’Open Group qui s’occupe des specs Unix.
Si vous êtes dans l’open source, il existe aussi une librairie libre qui vous permettra de patcher votre code existant afin de lui autoriser une longue et heureuse fin de vie bien après 2038.
Sachez enfin que ce bug de 2038 est très similaire à celui de l’an 2000, c’est à dire que la plupart des suggestions proposées par exemple par Steve Manley pour résoudre le problème du Y2K Bug sont applicables au bug de l’an 2038.
En tout cas, je compte sur vous pour programmer vos réveils quelques jours avant cette date du 19 Janvier 2038 afin de vous rappeler de moi car après même vos reveils planteront 🙂
J’espère en tout cas, qu’on survivra au réchauffement de la planète, aux guerres nucléaires, aux épidémies et à l’attaque des machines équipée d’intelligence artificielle, pour voir ça !
Rendez vous en 2038 les amis et en attendant suivez l’actu de ce bug sur le site officiel du bug de l’an 2038 !
Source
