Voici un article de Debian sur le problème des horloges 32 bits qui reviendront à 1900 en 2038.
https://wiki.debian.org/ReleaseGoals/64bit-time
Court résumé
L’article parle de l’objectif de passer à un temps 64 bits (time_t) sur les architectures 32 bits pour éviter le problème de l’année 2038, où le temps 32 bits existant pourrait revenir à 1900. Il est souligné que de nombreux systèmes actuels pourraient être affectés par ce problème, en particulier dans les domaines de l’automobile, de l’IoT, des téléviseurs, des routeurs, du contrôle des usines, de la surveillance et du contrôle des bâtiments, ainsi que des téléphones Android bon marché. Debian se concentre principalement sur l’architecture armhf comme étant la plus susceptible d’être utilisée dans de nouveaux systèmes au cours de la prochaine décennie. D’autres architectures 32 bits sont également concernées. Il est mentionné que la transition vers un temps 64 bits nécessitera des ajustements au niveau des bibliothèques et des API, et que des tests approfondis sont nécessaires pour garantir la compatibilité. Il est recommandé de construire les paquets avec les options DEB_BUILD_OPTIONS=abi=+lfs, _FILE_OFFSET_BITS=64 et _TIME_BITS=64, et de les tester sur des systèmes 32 bits. Il est également souligné que la transition vers un temps 64 bits est urgente et que des actions doivent être prises rapidement.
Résumé plus complet
Passation à 64 bits du type time_t dans Debian pour éviter le problème de l’année 2038
Description : Le but de cette mise à jour est d’utiliser un type time_t de 64 bits sur les architectures 32 bits pour éviter le problème du rollover qui peut renvoyer la date à 1900. Ce problème est décrit en détail sur cette page de glibc et sur ce site web. La conférence FOSDEM de février 2023 fournit également une bonne synthèse du statut actuel.
Dans les quinze prochaines années, il y a des systèmes qui continueront à avoir des problèmes et certains d’entre eux utilisent Debian ou ses dérivés. Les autres distributions distribuent désormais la prise en charge 32 bits, ce qui laisse Debian et son écosystème pour accueillir plus majoritairement ces nouveaux systèmes. La plupart des nouveaux composants utiliseront des systèmes basés sur la compilation à partir de sources comme OpenEmbedded, Alpine, Android ou Gentoo, mais le niche debianiser restera probablement pendant quelques années et certaines choses construites avec lui seront en usage/installées assez longtemps pour atteindre janvier 2038.
Debian est principalement préoccupée par l’architecture armhf, car elle est la plus probable à continuer à recevoir une utilisation significative dans les nouveaux systèmes au cours des prochaines décennies. Mais i386, armel, mipsel (et hppa, powerpc, m68k, et sh4 ports) sont également affectés.Les architectures 64-bit ne sont pas affectées.
Cette transition est similaire à la transition LFS (Support de fichiers systemes larges), où glibc fournissait aussi les APIs/ABIs 32-bit et 64-bit, mais ne fournissait pas de mécanisme de force d’utilisation de l’API/ABI nouvelle. Debian devrait donc dire à ses paquets « utiliser le temps 64-bit par défaut ».
Cet objectif est une extension de ReleaseGoals/LFS, car vous devez avoir LFS si vous avez 64-bit time_t (glibc le contraint).
Objectif :
L’objectif consiste à utiliser 64-bit time_t sur des architectures 32-bits pour éviter le problème de l’année 2038 lorsque le temps existant en int signed de 32 bits roulera et pourra potentiellement remettre la date à 1900. Il est expliqué en détail sur cette page de glibc et en général sur ce site web.
Ce talk FOSDEM donne une bonne vue d’ensemble du statut actuel (PDF).
Il n’y a plus qu’une quinzaine d’années avant que ce problème ne soit atteint et des systèmes qui en souffriront ont déjà été livrés. Nous devrions arrêter d’ajouter à ce problème. La plupart du calcul informatique, particulièrement celui qui utilise Debian ou ses dérivés, est maintenant effectué sur des architectures 64 bits où ce problème n’apparaît pas. Cependant, il y a encore beaucoup de calcul informatique coûtant en 32 bits et qui continue à être livré (automobiles, IoT, téléviseurs, routeurs, contrôle de plantes, surveillance et contrôle de bâtiments, téléphones mobiles Android bon marché). Certains de ces appareils pourraient utiliser Debian ou ses dérivés. D’autres distributions binaires abandonnent la prise en charge 32 bits (RedHat/Fedora l’ont déjà fait, le support de SUSE est non officiel), ce qui laisse supposer que ce qui reste est plus probablement dans l’écosystème Debian. La plupart de ces nouvelles machines fonctionneront avec des systèmes d’exploitation OpenSource tels que OpenEmbedded ou Alpine, Android ou Gentoo, mais le niche Debian basé est probablement restée pendant quelques années et certaines choses construites avec lui seront en usage/installées assez longtemps pour atteindre janvier 2038.
Ce sujet a été abordé dans cette conférence FOSDEM (PDF) et nous sommes actuellement à moins de 15 ans avant que ce problème ne soit atteint. Nous devrions arrêter d’ajouter aux problèmes en ajoutant de nouvelles machines ou en utilisant des distributions Debian ou dérivées. Cependant, il existe encore beaucoup de calcul fonctionnel coûte-sensible à 32 bits en cours de livraison et qui utiliseront peut-être Debian ou ses dérivées. Ce sont principalement des ordinateurs automobiles, IoT, télévisions, routeurs, contrôle de bâtiments, surveillance et contrôle, et smartphones Android bon marché.
Debian a décidé de faire une transition d’architecture intérieure pour tous les architectures 32-bit sauf i386, qui restera avec le temps_t existant en tant qu’architecture de compatibilité pour les binaires x86 anciens.
Cette transition aura des conséquences sur tout Debian, mais seulement bénéficiera les architectures 32-bit restantes. Il est donc important de faire cette transition efficacement pour ne pas retarder trop longtemps tout le système Debian. Les dommages de rupture sont probablement tombés sur les architectures 32-bit qui changent d’ABI.
Une analyse complète des modifications d’ABI a été effectuée en mai-octobre 2023 et il a été déterminé que environ 495 packages de bibliothèque ont changé d’ABI, et entre 5063 et 5975 packages qui dépendent de ces bibliothèques auront besoin d’une réédition sans changement. Approximativement 600-700 paquets Perl qui utilisent des modules XS (et dépendent de perl-abi-5.x.x ou libperl-5.xx) ont également besoin d’être traités.
Ce changement d’ABI est similaire aux transitions d’ABI antérieures telles que LFS (Support de fichiers systèmes larges) où glibc fournissait aussi les APIs/ABIs 32-bit et 64-bit, mais ne fournissait pas de mécanisme pour forcer l’utilisation de l’API/ABI nouvelle. Un mécanisme consistant, DEB_BUILD_OPTIONS=abi=+time64 a été implémenté par Debian pour forcer l’utilisation de l’API/ABI 64-bit.
Debian a décidé de faire une transition in-architecture pour tous les architectures 32-bits sauf i386. i386 restera avec le temps 32-bit, comme architecture de compatibilité pour les binaires x86 existants. Une nouvelle ‘i686’ architecture x86 utilisant le temps 64-bit et des fonctionnalités ISA plus récentes pourrait être créée si cela rencontrait un grand intérêt pour pousser 32-bit x86 vers son avenir limité.
Dans ce processus, il est important d’analyser les changements ABI des paquetages impliqués et de tester les paquetages affectés. Les développeurs travaillant sur cette transition apprécieront beaucoup les commandes/tests qu’ils peuvent exécuter pour vérifier que tout fonctionne correctement.
Aucune réponse