<html><head></head><body><div dir="auto">Sans compter ceux qui stockent un timestamp en 32 bits dans les enregistrements de leur base de donnée. Comme le dit au bien Marc, on a eu le problème de l'an 2000 (fortement lié aux pratiques de COBOL), mais le problème de 2038 est plus facile à éviter, mais encore faut-il que les développeurs en soient conscient ! <br><br></div>
<div dir="auto">dc<br><br></div>
<div dir="auto"><!-- tmjah_g_1299s -->Envoyé par <!-- tmjah_g_1299e --><a href="http://www.bluemail.me/r?b=15289"><!-- tmjah_g_1299s -->BlueMail<!-- tmjah_g_1299e --></a><!-- tmjah_g_1299s --> <!-- tmjah_g_1299e --></div>
<div class="gmail_quote" >Le 26 juin 2019, à 16:57, Marc SCHAEFER <<a href="mailto:schaefer@alphanet.ch" target="_blank">schaefer@alphanet.ch</a>> a écrit:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="blue">On Wed, Jun 26, 2019 at 04:15:10PM +0200, Miçhael Parchet wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> En l'an 2038, nous arriverons à la fin du 32 bits<br></blockquote><br>Je suppose que tu fais référence au problème du time_t POSIX 32 bits.<br><br>En fait, OpenBSD et NetBSD ont déjà résolu le problème pour les<br>plateformes embarquées 32 bits[1] en définissant time_t sur 64 bits<br>(ce qui est assez inefficace à gérer mais corrige le problème).<br><br>Pour Linux, est-ce aussi simple que de définir time_t (et les trucs<br>kernels) en 64 bits ? Oui, mais pour le moment ce n'est pas<br>fait, de plus, il y a le problème des applications:<br>il ne faut pas oublier que toute structure de données stockée doit<br>être également convertie.<br><br>Par exemple, j'ai pour des raisons historiques une VM avec plein de<br>trucs dedans: des bases de données dbm, du PostgreSQL, etc. J'avais<br>en fait virtualisé une vraie machine dans un conteneur OpenVZ (aujourd'hui<br>lxc) autour de 2007 et j'ai fait les mises à jour sans vraiment me préoccuper du<br>problème du 64 bits, même quand le host lui-même est passé en 64 bits.<br><br>J'ai deux options<br> a) je réinstalle, en séparant les diverses fonctionnalités dans plusieurs<br> containers, et en adaptant les configurations, puis en rechargeant<br> les données depuis des formats textes<br> b) je migre en-place à 64 bits<br><br>Je n'ai pas encore décidé.<br><br>Pour migrer en 64 bits, il ne suffira pas d'utiliser le script-qui-va-bien<br>de Félix qui permet de convertir une machine Debian 32 bits en 64 bits,<br>mais il faudra aussi dumper & recharger toutes ces dbs. Debian a<br>des scripts automatiques pour les mises à jour entre versions, il suffira<br>de les adapter.<br><br>Finalement:<br><br>Restera-t-il encore du 32 bits après 2038? Difficile de savoir. Le fait<br>est qu'il y a encore des applications en production dont le bug de l'an<br>2000 est latent (avec une fenêtre si date < 20 alors 20e siècle,<br>si >= 20 alors 19e siècle, par exemple, mais les développeurs ont<br>été créatifs), alors que cela fait déjà 19 ans. Et il n'y a que<br>19 ans d'ici à 2038.<br><br>[1] <a href="http://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html">http://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html</a><br><hr><br>gull mailing list<br>gull@forum.linux-gull.ch<br><a href="https://forum.linux-gull.ch/mailman/listinfo/gull">https://forum.linux-gull.ch/mailman/listinfo/gull</a></pre></blockquote></div></body></html>