Debian 13 passe son horloge en 64 bits pour éviter le bug de l’an 2038
-
Ce bug de l’an 2038 est similaire à celui de l’an 2000 : à cause d’un codage de la date dans un espace trop petit, le compteur risque de revenir à zéro une fois la limite atteinte. Pour le 1<sup>er</sup> janvier 2000, le risque était ainsi de voir la date revenir à 00, soit 1900.
Le problème réside cette fois dans le « timestamp Unix ». Il compte les secondes écoulées depuis le 1<sup>er</sup> janvier 1970 à minuit, heure UTC. Pour stocker cette valeur, les systèmes Unix et Linux se servent d’une valeur de type « signed 32-bit integer », dont la valeur positive maximale est de « + 2 147 483 647 ».
Dans la situation qui nous occupe à présent, cette valeur sera atteinte le 19 janvier 2038 à 03:14:07 UTC très précisément. La seconde suivante, le dépassement entrainera un retour à la valeur négative minimale de l’entier 32 bits, soit « - 2 147 483 64 », ce qui correspond à 1901.
Photo de Anirudh sur Unsplash
Face à un entier 32 bits limité, la solution est évidente : passer au 64 bits. Ce mouvement est en cours depuis un moment déjà, mais pas partout. Chez Debian, dont la distribution sert de socle à Ubuntu et donc à de très nombreux autres systèmes, ce changement sera officialisé dans la version 13, nommée Trixie.
Comme l’équipe l’indique, le travail n’a pas été de tout repos. Il ne suffit pas en effet de changer le codage de la valeur pour que tout s’enchaine : tous les paquets y faisant référence doivent être modifiés. Dans le cas présent, pas moins de 6 429 paquets ont été identifiés comme utilisant au moins une fois la variable.
Debian 13 et tous ces paquets repérés utiliseront donc le format time_t 64 bits, même sur les architectures 32 bits. Pour les systèmes existants, le time_t 32 bits sera laissé en place pour ne pas casser la compatibilité sur les anciennes architectures. Sur le matériel 64 bits (très largement majoritaire), la bascule sera automatique.
Ce changement dans le codage de la valeur intervient 12 ans et demi avant la manifestation du problème. Quant au 64 bits, il fait disparaitre « définitivement » le problème, puisque la limite ne sera atteinte que dans… 292 milliards d’années.
Source : next.ink
-
Ce bug de l’an 2038 est similaire à celui de l’an 2000 : à cause d’un codage de la date dans un espace trop petit, le compteur risque de revenir à zéro une fois la limite atteinte. Pour le 1<sup>er</sup> janvier 2000, le risque était ainsi de voir la date revenir à 00, soit 1900.
Le problème réside cette fois dans le « timestamp Unix ». Il compte les secondes écoulées depuis le 1<sup>er</sup> janvier 1970 à minuit, heure UTC. Pour stocker cette valeur, les systèmes Unix et Linux se servent d’une valeur de type « signed 32-bit integer », dont la valeur positive maximale est de « + 2 147 483 647 ».
Dans la situation qui nous occupe à présent, cette valeur sera atteinte le 19 janvier 2038 à 03:14:07 UTC très précisément. La seconde suivante, le dépassement entrainera un retour à la valeur négative minimale de l’entier 32 bits, soit « - 2 147 483 64 », ce qui correspond à 1901.
Photo de Anirudh sur Unsplash
Face à un entier 32 bits limité, la solution est évidente : passer au 64 bits. Ce mouvement est en cours depuis un moment déjà, mais pas partout. Chez Debian, dont la distribution sert de socle à Ubuntu et donc à de très nombreux autres systèmes, ce changement sera officialisé dans la version 13, nommée Trixie.
Comme l’équipe l’indique, le travail n’a pas été de tout repos. Il ne suffit pas en effet de changer le codage de la valeur pour que tout s’enchaine : tous les paquets y faisant référence doivent être modifiés. Dans le cas présent, pas moins de 6 429 paquets ont été identifiés comme utilisant au moins une fois la variable.
Debian 13 et tous ces paquets repérés utiliseront donc le format time_t 64 bits, même sur les architectures 32 bits. Pour les systèmes existants, le time_t 32 bits sera laissé en place pour ne pas casser la compatibilité sur les anciennes architectures. Sur le matériel 64 bits (très largement majoritaire), la bascule sera automatique.
Ce changement dans le codage de la valeur intervient 12 ans et demi avant la manifestation du problème. Quant au 64 bits, il fait disparaitre « définitivement » le problème, puisque la limite ne sera atteinte que dans… 292 milliards d’années.
Source : next.ink
@Raccoon a dit dans Debian 13 passe son horloge en 64 bits pour éviter le bug de l’an 2038 :
le problème, puisque la limite ne sera atteinte que dans… 292 milliards d’années.
Voilà, une fois de plus, on ne fait que repousser le problème!
Troll from London
-
@Raccoon a dit dans Debian 13 passe son horloge en 64 bits pour éviter le bug de l’an 2038 :
le problème, puisque la limite ne sera atteinte que dans… 292 milliards d’années.
Voilà, une fois de plus, on ne fait que repousser le problème!
@michmich a dit dans Debian 13 passe son horloge en 64 bits pour éviter le bug de l’an 2038 :
Voilà, une fois de plus, on ne fait que repousser le problème!
Exact, un sparadrap sur une jambe de bois, bien que je me demande s’il existera encore du linux en 2038 et des gens sur terre…
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
S'inscrire Se connecter