Em praticamente todas as culturas existe o conceito de "fim dos dias", um momento em que a humanidade - como a conhecemos - chegará ao fim por intermédio de algum evento catastrófico e de conseqüências terríveis. O sentimento de fim, embora sempre evitemos pensar nele diretamente, está presente no nosso subconsciente e povoa o imaginário do homem desde que abandonamos as cavernas e nos aventuramos mundo afora.
Tentar prever a chegada do fim também tem fascinado e feito estremecer as pessoas ao longo dos séculos. Diversas datas apocalípticas já foram decretadas por religiosos, místicos, mágicos, pensadores e adivinhos. Sem citar os casos medievais, onde praticamente toda data com um significado popular era pretexto para o fim do mundo.
A civilização evoluiu, mas o medo, que é um sentimento instintivo, não faz distinção de tecnologia ou de era. Já em 1910, quando os seres humanos começavam a gozar de consideráveis facilidades trazidas pela tecnologia, o mesmo medo primitivo tomava conta de populações inteiras: o planeta Terra passaria exatamente pelo rastro do cometa Halley e os gases venenosos flutuando pela atmosfera iriam pôr fim à existência de qualquer coisa que respirasse. Houve uma explosão na venda de máscaras que prometiam filtrar o ar e mais uma vez aprendemos que, em tempos de crise, sempre é possível faturar alto, mesmo que seja em cima da ignorância alheia.
O fim do mundo também estava previsto para o ano de 1999 e o próximo, segundo os pessimistas, vai ser em 2012... Se você estiver lendo esse artigo em 2013, é claro, significa que o mundo continua firme e forte (com uma ou outra guerrinha, doenças, desigualdade social e sogras, mas continua inteiro).
Atualmente as nossas maiores preocupações têm pouco a ver com maus espíritos e rastros de cometa. Vivemos num mundo quase totalmente informatizado mas tivemos o "nosso" primeiro fim do mundo anunciado para 1999, quando a ameaça chamada "Bug do Milênio" mostrou que o mundo informatizado tem um calcanhar de Aquiles.
O nosso calcanhar de Aquiles vinha de um problema herdado de códigos mais antigos e que acabam passando despercebidos ao longo dos anos simplesmente porque mesmo os códigos mais antigos podem funcionar bem, até que as limitações da época em que foram escritos começam a se transformar em problemas para os dias de hoje.
Os programadores de antigamente precisavam lidar com o problema de falta de memória e, de fato, cada byte economizado poderia significar uma grande economia ou, inclusive, se o software poderia ou não ser produzido. Cada letra (ou número) exibido na tela significava 1 byte de gasto; exibir uma data como 22 02 1960 queria dizer 8 bytes de memória a menos e a solução mais óbvia era cortar o "19" do ano, transformando a data em 22 02 60.
A solução não levava em conta que os códigos escritos sob esse conceito "econômico" poderiam sobreviver pelos próximos 40 anos e chegar ao dia 31 de dezembro de 99.
Basicamente, surgiu o risco de que sistemas vitais usando os anos com dois dígitos, depois do dia 31/12/99 zerassem os relógios de volta ao dia 1º de janeiro de 1900.
Conseqüentemente, taxas bancárias com 100 anos de juros seriam emitidas, passagens aéreas teriam 100 anos de atrasos e diversos softwares dependentes de calendários enfrentariam problemas.
O mundo todo se mobilizou num upgrade preventivo que custou milhões de dólares e eu ainda me lembro da cena mostrada pela TV, onde logo após a virada do ano de 1999 para 2000, operadores de sistemas comemoravam a não manifestação do bug (pouco se lixando para o fato de ser ano novo).
O Bug do Milênio foi derrotado, mas no melhor estilo de um vilão de histórias em quadrinhos, continuará a espreita para atacar numa outra oportunidade. De fato, o próximo problema já tem data e hora marcados: 03:14:07, na terça-feira do dia 19 de janeiro de 2038.
Este bug, chamado de Bug de 2038 ou Bug do Milênio Unix, irá afetar todos os sistemas 32 bits que calculam suas datas a partir da representação POSIX. Na representação de tempo POSIX, todo o tempo é baseado numa contagem feita em segundos e essa contagem começou no dia 1º de Janeiro de 1970, aumentando de segundo em segundo até os dias de hoje.
Se quiser descobrir a sua "hora UNIX" digite no terminal "date +%s". Essa é a quantidade de segundos que se passaram desde 01/01/1970.
O bug de 2038 ocorre porque a maioria dos sistemas tipo UNIX de 32 bits é programado em linguagem C, que trata os valores de tempo como números inteiros do tipo "signed" (que aceitam sinais positivos e negativos). Existe um valor máximo que os números do tipo "inteiro e com sinal" podem suportar e esse valor vai de -2.147.483.648 até +2.147.483.647, ou seja: começando de 00:00:00 em 1º de janeiro de 1970, o tempo UNIX suporta "somente" 2.147.483.647 segundos antes de zerar a contagem.
Alguns sistemas retornarão ao zero (que é 1970) e outros retornarão ao -2.147.483.648 (que é 1901).
O primeiro problema sério ocorrido por causa do bug de 2038 afetou os servidores AOL em 12/05/2006. Para garantir que nunca ocorresse time out numa requisição de banco de dados, os servidores estavam programados para trabalhar com timeouts um bilhão de segundos no futuro. Quando esse adianto de 1 bilhão de segundos atingiu a data fatídica de 2038, os servidores travaram.
A solução, no caso, é a migração para padrões de 64 bits, o que, espera-se, tenha ocorrido até 2038.
O próximo bug - que deve atingir os calendários calculados através de métodos de 64 bits - não é exatamente uma preocupação imediata: num domingo, no dia 4 de dezembro de 292.277.026.596 às 15:30:08 (UTC), as máquinas UNIX de 64 bits também enfrentarão o Bug de Data.
ADENDO
Mesmo nos dias de hoje ainda há profissionais que precisam trabalhar com quantidades limitadíssimas de memória e que ficam contando cada byte utilizado. Sistemas embarcados em memórias ROM são o melhor exemplo: medidores de luz e outros mecanismos simples que rodam longe de nossos olhos, gravados em memórias não voláteis e que, muitas vezes, carregam códigos antigos ou bugs potenciais, esquecidos pelo tempo mas que esperam pela oportunidade de se manifestarem. Ainda há, na verdade, muito código com mais de 20 anos rodando por aí e servindo de base para softwares do nosso dia a dia. O próprio Internet Explorer (pelo menos até a versão 6) e o Firefox trazem pedaços de código oriundos do velho Mosaic, que foi o primeiro navegador popular da história.
Até 2038 ainda teremos bastante tempo, mas nenhum especialista pode garantir que a migração atinja 100% das máquinas e que o bug de 2038 não terá nenhuma conseqüência.
SEU SISTEMA LINUX 32 BITS VAI BUGAR EM
Popularity: 65% [?]
Posts relacionados:
Loading ...
{ 1 trackback }
{ 10 comments… read them below or add one }
Acho que vou suicidar antes do bug acontecer…
Ótimo artigo, parabéns!
Então quer dizer que antes dos sistemas posix 64bits tiverem o bug da data os wins sofrerão o bug do ano 10.000!?
Será que daqui a quase a 20 anos finalmente vamos ter flash e java rodando bem no browser pra 64bits?! É bom lembrar que o processador de 64bits já existe há mais de 8 anos e demorou 3 anos pra ter um Linux 64bits.
Quanto à observação do Mosaic, bem… se você reparar bem, pra muita coisa não precisa “reinventar a roda”.
Ótimo artigo!
Muito interessante o artigo. Parabéns ao autor. Artigos como esse, fugindo um pouco do rigor técnico comum à computação, nos faz criar curiosidade sobre determinados assuntos que nem reparamos que existem, mas são reais e presentes na vida de muitos.
“De fato, o próximo problema já tem data e hora marcados: 03:14:07, na terça-feira do dia 14 de janeiro de 2038.”
Errado, será dia 19 de janeiro (do mesmo ano).
en.wikipedia.org/wiki/Year_2038_problem
Tiago, muito obrigado por apontar o erro. Não sei de onde digitei aquele 14… provavelmente por causa de um bug. Já corrigi.
Dois comentários:
1) Linux em 64 bits.
Sabemos de problemas com o Linux em emt64 mas isso não quer dizer que não temos Linux em 64 bits.
- 1º computador de 64 bits: IBM 7030 Stretch em 1961
- 1º Linux em arquitetura de 64 bits: em junho de 1994 John Hall convenceu a DEC e Linus para sobre portar o Linux para o processador Alpha.
Atualmente temos também Linux em Sparc e z-Series da IBM ambos de 64 bits.
Não podemos ficar pensando que Intel e AMD que implementam o emt64 são as unicas alternativas de 64 bits, talvez para nós reles mortais sim.
2) Limites do timestamp de TODOS os Unix que fazem cálculo de datas com inteiros de 32 bits com sinal (mesmo com um processador de 8 bits podemos fazer contas com inteiros de 64 bits).
Unix start date: 1970-01-01 00h00m00s UTC
Menor data (negativa): 1901-12-13 20h345m52s UTC
Maior data : 2038-01-19 03h14m07s UTC
Lembrar que o timestamp é calculado em UTC, assim diferentemente do Bug do Milênio onde a Austrália e o Japão seriam os primeiros a sentir os efeitos caos algo não tivesse sido corrigido. Nosso caso será simultâneo para todos os que usam cálculo de data com inteiros de 32 bits. Mas a solução também é bem mais simples, pois se sabemos que nossos sistemas usam inteiros de 32 bits para os cálculos de data basta substituir os inteiros e as bibliotecas de cálculo.
Fico por aqui. Saudações a todos.
Substituir os inteiros e as bibliotecas de cálculo de data 32 bits não é uma solução muito apreciada porque causaria um crash em diversos softwares. A solução mais eficaz seria mesmo a migração completa para 64 bits.
Existe um projeto que busca uma solução para o bug sem migrar, mas se eu escrevesse a respeito o post ficaria imenso (ainda mais) e nem eu leria. haha
Até lá já encontraram solução para o problema!