Le bug unix de l'an 2038 (?) intox ?

Pause Café
#1

salut a tous , qui connais cette histoire ??? qu’en pensez vous ??

[quote]En informatique, le bug de l’an 2038 est un problème similaire au bug de l’an 2000 qui pourrait perturber le fonctionnement d’ordinateurs 32 bits aux alentours du 19 janvier 2038, et plus particulièrement le 19 janvier 2038 à 3 h 14 min 7 s, temps universel[1].

Le problème concerne des logiciels qui utilisent la représentation POSIX du temps, dans lequel le temps est représenté comme un nombre de secondes depuis le 1er janvier 1970 à 0 heure. Sur les ordinateurs 32 bits, la plupart des systèmes d’exploitation concernés représentent ce nombre comme un nombre entier signé de 32 bits, ce qui limite le nombre de secondes à 231 - 1, soit 2 147 483 647 secondes (01111111 11111111 11111111 11111111 en binaire). Ce nombre maximum sera atteint le 19 janvier 2038 à 3 h 14 min 7 s (temps universel). Dans la seconde suivante, la représentation du temps « bouclera » (10000000 00000000 00000000 00000000 en binaire) et représentera -2 147 483 648 en complément à deux, et ainsi, l’ordinateur affichera la date du 13 décembre 1901.[/quote]

fr.wikipedia.org/wiki/Bug_de_l%27an_2038

#2

Des machines 32 bits en 2038 tournant sur un OS n’ayant pas prévu ce bug, hum pas gagné mais on va essayé le challenge.

#3

Je rebondis sur le sujet pour une question à propos du timestamp : Comment l’ordinateur le stocke-t-il ?(je suis pas sûr des -’, jamais su écrire quand il y en a deux)
Je veux dire, quand il est allumé, il suffit de réserver un petit espace mémoire où il augmente de 1 chaque seconde, mais quand il est éteint, au rallumage il ne sait pas combien de temps il a été éteint, non ?

#4

Effectivement… moi aussi je pense que j’aurais abandonné mon P4 d’ici là. :mrgreen:

Sinon j’avais essayé de modifier la date de mon ordi sous Lenny et je n’avais pas constaté ce bug…
Il a continué à donner l’heure et la date au delà de cette date fatidique.

#5

Le problème ne concerne pas seulement les systèmes qui tourneront en 2038 mais les logiciels POSIX actuels qui doivent manipuler des dates futures.

#6

C’est pour ça qu’il y a une pile sur ta carte mère qui sert à alimenter très légèrement ton pc quand la prise d’alimentation est enlevée. Car quand ta machine est éteinte mais l’alimentation branchée, tu pourra remarquer que ta carte mère est quand même alimentée.

#7

Salut,

[quote=“Glorf”]Je rebondis sur le sujet pour une question à propos du timestamp : Comment l’ordinateur le stocke-t-il ?(je suis pas sûr des -’, jamais su écrire quand il y en a deux)
Je veux dire, quand il est allumé, il suffit de réserver un petit espace mémoire où il augmente de 1 chaque seconde, mais quand il est éteint, au rallumage il ne sait pas combien de temps il a été éteint, non ?[/quote]

Il fait comme ta montre à quartz, il utilise la pile qui est cachée dans la grosse boite :laughing:

#8

je vais pas t’expliquer,il y a risques “d’amalgames sémantiques”, mais cet article t’éclaircira peut être: fr.wikipedia.org/wiki/Heure_Unix

[quote=“themorice”]Glorf a écrit:
mais quand il est éteint, au rallumage il ne sait pas combien de temps il a été éteint, non ?

C’est pour ça qu’il y a une pile sur ta carte mère qui sert à alimenter très légèrement ton pc quand la prise d’alimentation est enlevée. Car quand ta machine est éteinte mais l’alimentation branchée, tu pourra remarquer que ta carte mère est quand même alimentée.[/quote]

oui ,c’est ce qui garde l’heure matérielle à jour. mais ce n’est pas l’heure système qui elle est définie au démarrage du système.

pour ne pas “proférer trop d’approximations”, je conseilles la lecture de guidespratiques.traduc.org/vf/Ti … HOWTO.html

c’est pas de dernière fraicheur pour la config, allez voir par là: pool.ntp.org/fr/use.html

#9

C’est pour ça qu’il y a une pile sur ta carte mère qui sert à alimenter très légèrement ton pc quand la prise d’alimentation est enlevée. Car quand ta machine est éteinte mais l’alimentation branchée, tu pourra remarquer que ta carte mère est quand même alimentée.[/quote]
Je dirai même plus. Il y a une batterie qui alimente un circuit qui s’occuppe que de ça.
En gros le microprocesseur interroge une montre. Du coup le processeur modifie ou lit l’heure. Il n’incrémente rien du tout par programme et puis quoi encore j’ai besoin de ressource pour mater mes films.

#10

Merci pour cette explication, particulièrement pour le lien guidespratiques, c’est bien … pratique !

#11

[quote=“dmon”]
En gros le microprocesseur interroge une montre. Du coup le processeur modifie ou lit l’heure. Il n’incrémente rien du tout par programme et puis quoi encore j’ai besoin de ressource pour mater mes films.[/quote]
Pas tout à fait, tu as une horloge système hardware et une horloge «soft» gérée par le processeur. C’est infiniment plus efficace pour lire l’heure (temps d’accès) or celle ci est fréquemment utilisée. Tu peux voir la nuance entre les deux via date et hwclock

#12

C’est surtout que l’horloge “système” (qui utilise quand même un timer matériel) a une résolution beaucoup plus fine que l’horloge “matérielle” (100, 250, 300 ou 1000 interruptions par seconde selon la configuration du noyau à la compilation, contre 1 par seconde). Imaginez par exemple si la commutation de tâches ne pouvait se produire qu’une fois par seconde !

#13

Oui mais le noyau pourrait se contenter d’être interrompu régulièrement sans pour autant gérer une horloge interne…

#14

Il faut bien compter les interruptions pour générer des temporisations. Un compteur qui s’incrémente périodiquement, c’est une horloge.

#15

j’ai entendus dire qu’il faudrais retrouver un IBM 5100 pour surmonter le bug unix… ?
une idée ??

#16

Qu’est ce qu’on fait quand on l’a trouvé? On le mange? On le démonte? On le branche sur Internet? C’est du n’importe quoi ça à mon avis.

#17

[quote=“PascalHambourg”]Le problème ne concerne pas seulement les systèmes qui tourneront en 2038 mais les logiciels POSIX actuels qui doivent manipuler des dates futures.

Exactement.
On en a été victime au boulot (et on est pas les seuls)

Les utilisateurs de l’ERP BaaN ont dans leur paramétrage une valeur qui détermine sur quel horizon sont fait les calculs (CBN, stocks etc.), un simple nombre de jour qui additionné à la date du jour donne un horizon. Défini par défaut à 9999 pour simuler l’infini, il s’avère qu’il y a environ un mois (la flemme de calculer la date exacte), la date du jour + 9999 nous faisais tomber le 20 janvier 2038 :033
Du coup, nous, ainsi que de nombreuses boites à travers le monde, ont eu des problèmes ce week end là.

Ça m’a beaucoup fait rigoler.
Ainsi que la solution d’Infor “vous n’avez qu’a mettre 8888” ça reglera le problème. Si ils comptent à ce que les utilisateurs changent rapidement de matos / d’OS, ils sont pas rendus…