O apocalipse, o bug do milênio e o futuro

by LonelySpooky

apocalipseEm 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.

bugO 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% [?]

  • Share/Bookmark

Posts relacionados:

  1. Fedora 9 alfa e a arte do futuro desktop
  2. Google e o apocalipse

{ 1 trackback }

O apocalipse, o bug do mil
9 de dezembro de 2008 às 8:13

{ 10 comments… read them below or add one }

1 Ezek 9 de dezembro de 2008 às 10:17

Acho que vou sui­ci­dar antes do bug acontecer…

Responder

2 RicardoZ 9 de dezembro de 2008 às 11:46

Ótimo artigo, parabéns!

Responder

3 Mythus 9 de dezembro de 2008 às 14:36

Então quer dizer que antes dos sis­te­mas posix 64bits tive­rem o bug da data os wins sofre­rão o bug do ano 10.000!?

Será que daqui a quase a 20 anos final­mente vamos ter flash e java rodando bem no brow­ser pra 64bits?! É bom lem­brar que o pro­ces­sa­dor de 64bits já existe há mais de 8 anos e demo­rou 3 anos pra ter um Linux 64bits.

Quanto à obser­va­ção do Mosaic, bem… se você repa­rar bem, pra muita coisa não pre­cisa “rein­ven­tar a roda”.

Responder

4 Irio Musskopf 9 de dezembro de 2008 às 15:09

Ótimo artigo!

Responder

5 Doidêra 9 de dezembro de 2008 às 21:53

Muito inte­res­sante o artigo. Para­béns ao autor. Arti­gos como esse, fugindo um pouco do rigor téc­nico comum à com­pu­ta­ção, nos faz criar curi­o­si­dade sobre deter­mi­na­dos assun­tos que nem repa­ra­mos que exis­tem, mas são reais e pre­sen­tes na vida de muitos.

Responder

6 Tiago Myhro 10 de dezembro de 2008 às 1:40

“De fato, o pró­ximo pro­blema já tem data e hora mar­ca­dos: 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

Responder

7 LonelySpooky 10 de dezembro de 2008 às 11:03

Tiago, muito obri­gado por apon­tar o erro. Não sei de onde digi­tei aquele 14… pro­va­vel­mente por causa de um bug. Já corrigi.

Responder

8 Flávio RB 10 de dezembro de 2008 às 8:01

Dois comen­tá­rios:

1) Linux em 64 bits.

Sabe­mos de pro­ble­mas com o Linux em emt64 mas isso não quer dizer que não temos Linux em 64 bits.

- 1º com­pu­ta­dor de 64 bits: IBM 7030 Stretch em 1961

- 1º Linux em arqui­te­tura de 64 bits: em junho de 1994 John Hall con­ven­ceu a DEC e Linus para sobre por­tar o Linux para o pro­ces­sa­dor Alpha.

Atu­al­mente temos tam­bém Linux em Sparc e z-Series da IBM ambos de 64 bits.

Não pode­mos ficar pen­sando que Intel e AMD que imple­men­tam o emt64 são as uni­cas alter­na­ti­vas de 64 bits, tal­vez para nós reles mor­tais sim.

2) Limi­tes do times­tamp de TODOS os Unix que fazem cál­culo de datas com intei­ros de 32 bits com sinal (mesmo com um pro­ces­sa­dor de 8 bits pode­mos fazer con­tas com intei­ros de 64 bits).

Unix start date: 1970-01-01 00h00m00s UTC

Menor data (nega­tiva): 1901-12-13 20h345m52s UTC
Maior data : 2038-01-19 03h14m07s UTC

Lem­brar que o times­tamp é cal­cu­lado em UTC, assim dife­ren­te­mente do Bug do Milê­nio onde a Aus­trá­lia e o Japão seriam os pri­mei­ros a sen­tir os efei­tos caos algo não tivesse sido cor­ri­gido. Nosso caso será simul­tâ­neo para todos os que usam cál­culo de data com intei­ros de 32 bits. Mas a solu­ção tam­bém é bem mais sim­ples, pois se sabe­mos que nos­sos sis­te­mas usam intei­ros de 32 bits para os cál­cu­los de data basta subs­ti­tuir os intei­ros e as bibli­o­te­cas de cálculo.

Fico por aqui. Sau­da­ções a todos.

Responder

9 LonelySpooky 10 de dezembro de 2008 às 11:07

Subs­ti­tuir os intei­ros e as bibli­o­te­cas de cál­culo de data 32 bits não é uma solu­ção muito apre­ci­ada por­que cau­sa­ria um crash em diver­sos softwa­res. A solu­ção mais efi­caz seria mesmo a migra­ção com­pleta para 64 bits.
Existe um pro­jeto que busca uma solu­ção para o bug sem migrar, mas se eu escre­vesse a res­peito o post fica­ria imenso (ainda mais) e nem eu leria. haha

Responder

10 Marcola 5 de outubro de 2009 às 11:10

Até lá já encon­tra­ram solu­ção para o problema!

Responder

Leave a Comment

You can use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre user="" computer="" escaped="">

Previous post:

Next post: