Ano novo mas problema velho. Entenda o bug que poderia comprometer todos os sistemas baseados em UNIX que utilizam o padrão POSIX, incluindo o Linux.
| Se você apoia nosso site, desative o AdBlock quando visitá-lo, inclusive em Mobile!
Os anúncios são poucos e não invasivos. Se quiser contribuir com nosso trabalho, clique em qualquer banner de sua preferência, exceto dos Parceiros. Mais detalhes clicando aqui.
Vamos abordar um pequeno bug que existe no código do Linux mas que está aos poucos sendo mitigado para evitar problemas para quando a bomba estourar, á 00:00 de 1o de Janeiro de 2038.
Antes de prosseguirmos com este que, teoricamente, poderia representar uma ameaça ao mundo baseado no UNIX, vamos ao contexto histórico do Bug do Milênio e o por quê desse “problema de 2038” ser uma mera curiosidade da estreia da sessão “Você Sabia?” do site, e não de fato um alerta ou aviso!
O Bug do Milênio
Na década de 1960, com a solidificação da informática, foi necessária a adoção de diversos padrões para garantir a compatibilidade entre os diversos tipos de hardware e os softwares escritos para eles. Numa época em que cada byte de memória economizado representava economia de dinheiro, (até porque hardware valia uma fortuna) muitos destes padrões adotavam formas resumidas para armazenar dados. Ainda hoje centenas destes padrões estão em vigor, embora muitos tenham sido substituídos para se atualizar com a flexibilidade dos novos hardwares disponíveis.
Nos sistemas mais antigos, como aqueles na linguagem COBOL e semelhantes, as datas eram armazenadas com apenas 2 dígitos finais para o ano, ficando os restantes iniciais implicitamente entendidos como sendo “19”.
Ou seja, 1975, por exemplo, seria representado apenas como “75”.
Desta forma cada data armazenada deixava de ocupar oito bytes (dois para o dia, dois para o mês e quatro para o ano), e passava a ocupar somente seis bytes (somente dois no ano).
A opção por representar as datas desta forma vinha da necessidade real de economia de memória e espaço de armazenamento. Hoje isso parece insignificante mas na época foi o suficiente para justificar a adoção do padrão, tamanho o custo das memórias e dispositivos de armazenamento.
Para se ter uma ideia melhor, imagine um banco de dados com vários campos, entre eles data de nascimento, data de casamento e data de cadastro. Para cada registro a economia nas três datas totaliza seis bytes. Se o banco de dados tiver dez mil registros são 60kB a menos, o que era significativo numa época em que os discos tinham o tamanho de 180kB.
O Bug
Como todas as datas eram representadas por somente 2 dígitos, os programas assumiam o “19” na frente para formar o ano completo. Assim, quando o calendário mudasse de 1999 para 2000 o computador iria entender que estava no ano de “19” + “00”, ou seja, 1900. Os softwares mais modernos, que já utilizavam padrões mais atuais, não teriam problemas em lidar com isso e passariam corretamente para o ano 2000, mas constatou-se que uma infinidade de empresas e instituições de grande porte ainda mantinham em funcionamento programas antigos, em função da confiança adquirida por anos de uso e na sua estabilidade. Para além disso, temiam-se os efeitos que poderiam ser provocados no hardware pelo sistema BIOS, caso este reconhecesse apenas datas de dois dígitos.
Caso as datas realmente “voltassem” para 1900, clientes de bancos veriam suas aplicações dando juros negativos, credores passariam a ser devedores, e boletos de cobrança para o próximo mês seriam emitidos com cem anos de atraso.
O bug ficou conhecido como “Y2K”
Correções
Um exemplo de técnica de compensação ao bug pode ser encontrado no velho sistema em COBOL da empresa brasileira Espiral Informática: o sistema adicionava 1900 ao ano sempre que este fosse maior do que 25. E adicionava 2000 a todos os anos anteriores a 25. Assim, “24” seria interpretado como 2024, e “26”, como “1926”. Já “85” era interpretado como 1985. Este sistema tinha vida útil até 2025, data escolhida de forma arbitrária pelos desenvolvedores, possivelmente na crença de que em 2025 o sistema já teria sido substituído por simples obsolescência.
Consequências
Surpreendentemente, houve poucas falhas decorrentes do Bug do Milênio, que se revelou quase inofensivo apesar de ter gerado uma onda de pânico coletivo, especialmente nos países nos quais os computadores estavam mais popularizados. Todo esse pânico foi injustificado, porque a maioria das empresas e dos consumidores domésticos havia adquirido computadores novos ou fizeram a atualização para sistemas operativos preparados para o problema. Além disso, o grande desenvolvimento informático ocorreu na segunda metade da década de 1990 (não nas décadas de 1960 ou 1970, quando apenas grandes empresas possuíam os supercomputadores que tinham esse erro), quando os sistemas já estavam preparados para o problema. Os velhos computadores afetados pelo erro foram sendo substituídos ao longo da década de 1990, com o advento da Internet e do Windows 95, o que contribuiu para um número muito reduzido de ocorrências de problemas no mundo inteiro.
O assunto gerou muita polêmica devido aos grandes lucros gerados para as empresas de informática, foi alvo de matérias copiosas na imprensa e deu até origem a vários filmes. Hoje é considerado como um dos casos registrados pela história de pânico coletivo vazio de fundamentos, uma versão moderna do “temor do fim do mundo” que acometeu os povos da Europa Medieval na virada do ano de 999 para 1000.
Posix Epoch
Os sistemas que operam sob o padrão POSIX utilizam uma forma diferente de calcular datas. Eles não registram dia, mes e ano como os tradicionais 8 bytes, mas sim apenas segundos a partir do UNIX Epoch!
A “Era UNIX”, “Posix Time”, “UNIX epoch” ou “UNIX Timestamp” teve início no dia a 1 de janeiro de 1970. O nome se deve ao fato de esta data, dia 1 de janeiro de 1970 às 00:00:00 do Tempo Universal Coordenado (UTC) no calendário gregoriano proléptico, ser o marco zero do sistema de calendário usado pelo sistema operacional UNIX, cujo desenvolvimento começou em 1969.
O horário UNIX, definido como o número de segundos passados desde o epoch, não considerando segundos bissextos, é largamente utilizado em sistemas operacionais do tipo UNIX, bem como em outros sistemas. Ele não é uma representação linear nem uma representação verdadeira do tempo UTC, por não considerar os segundos bissextos (e.g. 31-12-1998-12 23:59:60).
O Curioso Problema do Ano 2038
O problema do ano 2038 (também conhecido como Y2K38, em referência ao Bug do Milenio cujo nome era Y2K) é uma falha na representação de datas em computadores, que pode causar erros em alguns programas de computador quando chegar o ano de 2038 cuja base era a mesma do bug do milênio mas de forma mais delicada, pois afeta os programas e sistemas sob POSIX, pois grande parte deste software foi desenvolvido na linguagem C.
Na maioria dos sistemas de 32 bits, o tipo de dados time t, utilizado para armazenar esta contagem de segundos, é um inteiro de 32 bits do tipo signed (considera o sinal). O último registro de tempo que pode ser representado por este formato, seguindo o padrão POSIX, é 03:14:07 na terça-feira 19 de janeiro de 2038 (UTC). Após este momento a data será representada por um número decimal negativo que, dependendo da implementação, corresponderá ao ano 1970 ou 1901. Este valor para a data corrente certamente resultará em erros de cálculo e de funcionamento na maior parte dos programas em execução pelo sistema.
Possíveis Soluções
Não há maneira simples de resolver este problema para os sistemas existentes. Alterar a definição do time_t para 64 bits pode quebrar a compatibilidade binária de softwares, dados persistidos e de qualquer sistema que manipule datas representadas no formato binário. Alterar o time_t para um inteiro de 32 bits unsigned (não considera o sinal) pode alterar vários programas que trabalham com diferenças de tempo.
A maioria dos sistemas que suportam a arquitetura de 64 bits já suportam o time_t de 64 bits. A migração para esta arquitetura já está em andamento e muitos esperam que ela esteja completa até 2038. Porém, milhões de sistemas de 32 bits foram instalados até o ano de 2006, muitos em sistemas embarcados, e é muito incerto se eles serão totalmente substituídos até 2038.
Apesar de, normalmente, os sistemas serem atualizados num prazo de 18-24 meses, os sistemas embarcados podem operar sem alterações por toda a vida do sistema que controlam. A utilização do time_t de 32 bits foi codificada em alguns formatos de arquivo, como o ZIP, o que significa que o problema pode permanecer por um longo período após a expiração da vida útil das máquinas envolvidas.
AMD64 foi a solução!
Esse medo todo, sob o Bug de 2038 acontecer, veio numa época de idos de 2001 quando perceberam que o padrão POSIX de tempo não conseguiria representar uma data maior que 2038. Porém á epoca as melhores tecnologias existentes para uso civil consistiam basicamente de hardware de 32 bits.
O bug de 2038 só vai afetar kerneis baseados em UNIX (UNIX®, BSD, Linux, macOS e etc) de hardwares e softwares da linha 32 bits!
A utilização de valores de 64 bits introduz um novo “corte” na data em aproximadamente 290.000 milhões de anos, num domingo em 4 de dezembro do ano 292.277.026.596. Claramente este problema não é uma questão imediata! Considerando o fator obsolescência de hardwares e as proprias distros abandonando as versões 32 bits com o passar do tempo, até 2038 chegar estaremos longe de ter corrido algum risco de problemas com o Bug do Ano 2038.
Kernel Linux 5.0
O kernel Linux já vem se preparando há anos para o ano 2038 e esse trabalho ainda está em andamento com o kernel Linux 5.0 em desenvolvimento.
Os desenvolvedores do kernel Linux, possuidor de cerca de 20 milhões de linhas de código, tem trabalhado para resolver o problema “Y2038”, mas não é tarefa fácil e ainda vão-se muitos anos até estar totalmente remediado.
A previsão é que o bug seja plenamente resolvido até o fatídico ano de 2038 chegar.
#UrbanCompassPony
Fontes:
Phoronix
Wikipedia 1
Wikipedia 2
Wikipedia 3
Autodidata, me aprofundei em sistemas operacionais baseados em UNIX®, principalmente Linux. Também procuro trazer assuntos correlacionados direta ou indiretamente, como automação, robótica e embarcados.