O ano de 2038 ainda é mais de duas décadas de distância, mas editor LWN.net e de longa data do kernel Linux cronista Jon Corbet acredita desenvolvedores de software deve estar pensando sobre essa data agora, particularmente no mundo Linux.
Corbet levantou a questão em seu discurso anual "Kernel Report" na Cimeira Linux Foundation Collaboration em Santa Rosa, Califórnia esta semana. "É hora de começar a se preocupar", disse ele.
A questão é similar ao bug Y2K temida, em que uma deficiência de longa data na forma como alguns computadores registam valores de tempo é devido a causar estragos em todos os tipos de software, desta vez em 2038.
Este último problema se resume aos "time_t" códigos de tempo utilizados por outros sistemas operacionais Unix-Linux compatíveis e. Porque eles foram especificados como valores de 32 bits - para trás nos primeiros dias de Unix, quando 2038 foi quase um século de distância - eles estão indo eventualmente funcionar para fora de bits com os quais a assinalar fora segundos. Especificamente, que vai acontecer exatamente 03:14:07 GMT em 19 de janeiro de 2038.
Então, por que se preocupar agora, quando ainda temos décadas para resolver o problema?
Jon Corbet acha que o tempo para enfrentar 2038 é agora
"O simples fato da questão é que os sistemas estão sendo construídas e implantadas agora que ainda estará em serviço de 23 anos a partir de agora", disse Corbet. "Os sistemas baseados em Linux estão sendo colocados em automóveis, para a construção de sistemas de controle, em usinas de energia, e em quem-sabe-quantos outros lugares onde eles vão simplesmente sentar lá e fazer o seu trabalho até que se esgote time_t de bits. E então eles não vão mais trabalhar. "
Uma vez que está instalado e esquecido, estes sistemas serão muito difíceis de detectar antes do ano de 2038 bug salta para mordê-los, disse Corbet. Além do mais, muitos deles será difícil, senão impossível, remendo - é por isso que os desenvolvedores devem parar de enviá-las, o mais rápido possível.
Mas a mudança para valores mais longos de tempo não é tão fácil quanto parece, porque fazer tais mudanças, invariavelmente, quebra de código que depende da especificação mais velho.
No caso do kernel do Linux, enquanto o código de cronometragem núcleo foi atualizado para solucionar o problema do ano 2038, ao longo de 2014, muitas rotinas nas camadas exteriores do grão ainda estão suscetíveis ao erro.
"Por exemplo, o sistema de arquivos ext3 vai quebrar", disse Corbet. "Eu não sei se isso nunca vai ficar fixo, ou se vamos só espero que ninguém está usando ext3 até lá. Espero que muitas pessoas não estão usando-o mesmo agora."
Muitas chamadas de sistema - os mecanismos pelos quais aplicações falar com o kernel - também terá de ser corrigido, ou aplicações, também, pode quebrar. E além do próprio kernel, as várias bibliotecas C atualmente em uso - como a biblioteca GNU C (glibc) que normalmente é fornecido com sistemas Linux - irá também precisam de atualização.
"Houve algumas conversas que tenho visto com os desenvolvedores da biblioteca C, então as coisas estão ficando pensado. Mas eu não sei o que há qualquer coisa parecida com um plano sério neste momento", disse Corbet. "Em termos de aplicações, na verdade, de fixação que lidam com este problema, bem ... isso não acontece, no entanto, tanto quanto eu posso dizer."
Enquanto ele está longe de ser tarde demais para abordar estas questões, no entanto, a cada ano que os desenvolvedores de produzir software que não leva em conta apenas 2038 agrava o problema.
"Se continuarmos a distribuir software que tem este problema nele, estamos a criar problemas para o futuro, e não quero fazer isso", disse Corbet. "O tempo de corrigi-lo é agora." ®
via Alimentação (Feed)
Nenhum comentário:
Postar um comentário