RPi souffrira-t-il du bug Y2K38?

Par curiosité, qu'arrivera-t-il aux modèles RPis A et B le 19 janvier 2038 à 03h14: 07 AM GMT? Sont-ils affectés par le bug Y2K38 ?

hardware system-clock bugs

— DaGhostman Dimitrov
source

Combien en attendez-vous encore?

— Thorbjørn Ravn Andersen

@ ThorbjørnRavnAndersen pour être honnête, je crois que le RPi a un grand avenir et il y en aura encore beaucoup (éventuellement des modèles C ou supérieurs mais ..)

— DaGhostman Dimitrov

Dans ce cas, réglez l'horloge et voyez.

— Thorbjørn Ravn Andersen

Je n'ai pas pensé à ça ..: D

— DaGhostman Dimitrov

Quel que soit l'avenir du pi, il est probable que ni lui ni rien n'utilisera toujours un processeur 32 bits dans 25 ans. Selon wikipedia, les systèmes 64 bits utilisent un 64 bits time_t, ce qui en fait le problème Y292G , que ni nous ni le soleil ne vivrons.

— goldilocks

Réponses:

Oui.

Voici la sortie d'une session SSH vers mon Pi exécutant OpenELEC.

Il se bloque après avoir atteint Y2K38. Non seulement la session SSH elle-même cesse de répondre, mais OpenELEC se bloque également.

J'espère (et j'espère!) Qu'en 2038, un correctif aura été publié.

^{Cela, ou votre question recevra beaucoup de votes positifs en 24 ans.}

entrez la description de l'image ici

— Ce gars brésilien
source

Je suis surpris que vous ayez pu ouvrir une session SSH avec une machine avec une date aussi folle. +1 pour l'avoir essayé.

— einnocent

@einnocent Pourquoi ne pourrais-je pas pouvoir? Y a-t-il une sorte de comparaison temporelle sur les spécifications de négociation SSH qui l'empêcherait? D'ailleurs, j'ai changé l'heure après l'établissement de la connexion. De plus, l'horloge Pi était déjà fausse de toute façon (de quelques mois, des années, je ne me souviens plus): P

— That Brazilian Guy

En modifiant l'heure de la pré-connexion, je comprends que de grandes différences d'horloge peuvent entraîner des problèmes avec certaines poignées de main de sécurité, bien que je ne connaisse pas SSH en particulier. Avec un changement post-connexion, je pouvais imaginer que SSH panique soudainement en découvrant qu'il avait une connexion ouverte depuis 34 ans. Je suppose qu'il y a une petite (mais non nulle) chance que SSH ait simplement mis fin à la connexion à ce moment magique. Mais vraiment, je suis convaincu de votre réponse :)

— einnocent

@einnocent Il ne m'est pas venu à l'esprit que SSH pouvait penser qu'il était "ouvert depuis 24 ans" et se bloquer. Je vais réessayer avec, disons, 22 ans. Mais je pense que ce n'est pas la cause, car il se bloque exactement en atteignant Y2K38

— That Brazilian Guy

En fait, le Raspberry Pi (matériel) ira bien. Il ne contient pas de RTC, donc cela dépendra du système d'exploitation que vous utilisez.

Mais l'IIRC toutes les versions 32 bits de Linux ont ce problème. Il y a quelque temps (environ 10 ans), Linus a déclaré qu'il n'était pas intéressant de résoudre ce problème sur les plates-formes 32 bits et que toutes les plates-formes Linux 64 bits avaient à l'époque 64 bits time_t. Il a peut-être changé d'avis depuis lors, bien sûr. Le meilleur lien vers cela que je peux trouver est http://permalink.gmane.org/gmane.linux.kernel/1184914 - qui n'est pas le même, mais exprime une intention similaire.

Ce ne sera pas une chose particulièrement difficile à changer, mais cela forcerait un changement dans les ABI du noyau. Ce qui est un problème en soi.

Mais, RiscOs utilise un temps de 40 bits (centiseconde), mais avec une époque différente. ( https://www.riscosopen.org/wiki/documentation/show/OS_Word%2014_3 ) - Je fais ce remplissage quelque temps en 2318 - [calc était: 1970 + ((2 ^ 40) / 100) / (60 * 60 * 24 * 365,25)]

Android, bien sûr, utilise le noyau Linux. Et je suis sûr que j'ai manqué d'autres options.

— rgammans
source

Tel qu'il est actuellement implémenté, le Raspberry Pi subira le sort du bogue répertorié, si aucun changement de logiciel n'est effectué.

La plupart des machines modernes font le saut vers les processeurs 64 bits, mais je ne serais pas du tout surpris de voir des processeurs traditionnels 32 bits à ce stade. Il existe des solutions logicielles qui pourraient et devront résoudre le problème.

Il me semble que le correctif le plus probable serait de mettre à jour Epoch pour commencer à quelque chose comme le 1er janvier 2000. Bien que cela ne retarde pas le bogue, il le réinitialisera certainement dans un avenir prévisible.

— Jacobm001
source