O que foi o Bug do Milênio?

Há mais de 15 anos as pessoas entraram em estado de alerta por conta de uma possível revolução das máquinas. Alguns acreditavam numa revolução, outros achavam que os eletrônicos iam todos parar de funcionar da noite para o dia, outros achavam que eles ficaram inutilizáveis, enfim, ninguém entendia bem o que estava acontecendo, mas em uma coisa todos concordavam: algo de ruim iria acontecer.

A notícia em tom de alerta popularizou-se nos últimos meses de 1999, quando diversas previsões surgiam constantemente e davam conta de quem o mundo não passaria da virada do milênio (em uma época em que a internet engatinhava - principalmente no Brasil - a boataria era ainda mais forte).

Entre estas previsões pessimistas estava aquela chamada de Bug do Milênio, talvez a única realmente possível de acontecer, mas claro, não nas proporções com as quais o falatório dava conta de espalhar.

Até hoje o assunto é motivo de confusão, curiosidade e informações desencontradas. Portanto, se você já nasceu no "novo" milênio ou se viveu o Bug, mas até hoje não entendeu direito o que foi e o que podia ter acontecido, continue acompanhando esse texto e hoje você vai entender porque nos escapamos de uma boa.

Origens do problema

Para entender o bug, primeiro temos que nos situar no momento em que vivíamos naquela época. Adianto que eram tempos difíceis: Um bom computador tinha 10 Gb de HD, 128 MB de memória RAM, internet discada de 28 kbp/s e os disquetes estavam a pleno vapor. Estas eram algumas das características das máquinas naquele distante ano 1999/2000.

Os programas feitos para rodar nesses sistemas, é claro, obedeciam ao padrão tecnológico da época, que se resumia em "menos é mais" (Masterchef™). Assim, quanto menos consumo de recursos, mais adaptável e compatível com o mercado (máquinas de 32Mb de memória ainda eram realidade em algumas empresas, por exemplo).

Porém, esse não era o cerne do problema. Para entender o início de tudo temos de voltar aos anos 60, quando uma máquina não tinha nem mesmo monitor e os recursos de hardware são incompreensíveis se analisarmos hoje em dia (a primeira memória RAM possuía 1 kilobyte e só foi surgir em outubro de 1970).

Foi nesse cenário de transição entre o hobbysmo e o profissionalismo que começaram a surgir os primeiros códigos mais sólidos e comerciais.

Nesta época não existiam sistemas operacionais (embora não tenha sido o primeiro, o popularo Windows só viria em 1980, ) e cada máquina podia funcionar de uma forma totalmente diferente da outra, dependendo de como foi montado pelo usuário. Assim, para que os computadores pudessem se popularizar, primeiro foi preciso criar padrões mínimos que pudessem garantir a compatibilidade entre diferentes hardwares. Em outras palavras: garantir que um software produzido para máquina X, fosse rodar na máquina, máquina Y, etc.

Nesta onde de início da computação e padronização, um deles vem a ser o ponto chave de toda a nossa história. Visando diminuir custos de hardware e enxugar naquilo que fosse possível os programadores eram instruídos a economizar cada bit possível (o kilobyte de armazenamento, na época, podia chegar a custar até 100 dólares).

Assim, um recurso que se adotou de maneira geral foi a abreviatura das datas. Por exemplo: para o computador guardar a data 18/02/1974 ele precisaria de 8 bytes, mas se ele armazenasse somente o 18/02/74 esse custo cairia para 6 bytes. Parece um bom negócio, não?

Não entendeu como isso podia ser útil? Olhe o exemplo: Um determinado banco de dados que armazene o nascimento e a data de cadastro de alguém. São 2 datas armazenadas por registro e no sistema mais econômico são poupados incríveis 4 bytes por cadastro. Agora suponha que esse banco de dados tivesse 100 pessoas cadastradas. No final das contas o sistema novo iria gerar uma economia de 40 bytes. Menos que uma imagem de péssima qualidade hoje em dia, mas não podemos esquecer que em nos anos 60 um "HD" típico tinha de 160Kb armazenamento total.

Medida implementada, sucesso total. O problema é que esse padrão não seria alterado, mesmo com o passar das décadas. E assim chegaríamos no final dos anos 90: com os programas armazenando dd/mm/aa.

Mas o que tem de ruim nisso?

A treta

Armazenar somente os 2 últimos dias do ano não tem problema quando você está no mesmo século, afinal, a máquina - e nós também - compreendia perfeitamente que antes dos dígitos correspondentes ao havia um "19" implícito.

Mas o fim do século chegou e com ele o "19" deveria ser alterado para "20". Nós não temos nenhum problema em entender isso, pois somos racionais, porém, não podemos dizer o mesmo das máquinas. Como elas só compreendem o que foram programadas para compreender, na virada de 31 de dezembro de 1999 para 01 janeiro de 2000 os sistemas do mundo inteiro retornariam a 01 de janeiro de 1900.

O iminente problema era conhecido desde 1958, pelo menos, quando Bob Bemer - um dos pioneiros da computação e dos programadores da IBM - alertou sobre o que poderia ocorrer dali algumas décadas. Mais do que isso: ele embarcou em uma missão pessoal pelos próximos 20 anos em tentou conscientizar os programadores de que era melhor utilizar os 4 dígitos para o descrever o ano e fazer com que eles mudassem o jeito como criavam seus códigos. Mas como já sabemos, ninguém deu muita bola.

Aliás, Alan Greenspan, um importante economista americano e futuro Presidente da Reserva Federal - algo como um ministro da economia no Brasil - que começou a carreira escrevendo seus próprios códigos nresumiu a história toda, em 1998, com as seguintes palavras:

"Eu sou um dos culpados deste problema. Eu costumava escrever esses programas nos anos 1960 e 1970, orgulhoso de ser capaz de retirar alguns elementos do meu programa como não ter que colocar o "19". Naquela época, era muito importante. Gastávamos muito tempo com exercícios matemáticos antes de começarmos a escrever nossos programas para que eles pudessem ser os mais econômicos possíveis. Não fazíamos ideia de que esses programas durariam tanto. Por isso estão tão mal documentados. Se eu voltasse a olhar para alguns dos meus programas de 30 anos atrás teria muito trabalho para entender o que fiz."

Assim a falha ficou esquecida até, pelo menos, 1985 quando o livro Computers in Crisis, escrito por Jerome e Marilyn Murray a trouxe novamente à tona e alertou a todos do que estava por vir.

Mas com repercussão restrita somente ao meio computacional foi somente com a reedição do livro, feita em 1996, que o medo do bug começou a tomar proporções surreais e desencadeou-se uma verdadeira corrida pelas possíveis soluções e atualizações de tudo que fosse possível (tanto software como hardware). Existem relatos de programadores de COBOL, já aposentados, que foram recontratados para mexer nos sistemas criados por eles décadas atrás.

Claro que os programas e sistemas mais modernos já estavam preparados e não sofreriam mais com esse "defeito" no código, porém, tais sistemas modernos eram raros e muitas empresas - algumas de grande porte, inclusive - ainda não tinham migrado e, até então, nem mesmo tinham a intenção de o fazer, fosse pela confiança nos sistemas antigos, fosse por sua estabilidade.

E assim meus amigos, a cada dia que chegávamos mais perto da virada, maior era alarmismo. O Secretário de Defesa dos Estados Unidos, John Hamre, chegou a declarar, na época, que o Bug Y2K - como era chamado nos EUA - era  

 o equivalente ao El Niño e traria surpresas desagradáveis ao mundo

O medo era que o mercado financeiro, por exemplo, entraria em colapso no exato momento da troca de ano. Naquele instante as contas com saldo positivo passariam a ser negativas, os credores passariam a ser devedores, os boletos de cobrança sairiam com 100 anos de atraso, as aplicações dariam juros negativos, etc.

Além da quebra no sistema de finanças temia-se também:

• Usinas nucleares entrando em confusão e até explodindo;
• Aviões caindo devido a problemas com os computadores de bordo;
• Sistemas de transmissão de energia e fornecimento de água entrando em pane;
• Toda a sorte de sistemas automatizados desregulados e fora de controle;
• Em casos extremos (leia o parágrafo abaixo) até guerras civis, uma nova cisma da igreja e o apocalipse.

Grupos de religiosos fundamentalistas, messiânicos, movimentos anti-sociedade e o pessoal das conspirações (entre outros grupos tão dignos quanto) adoraram a onda. O Bug do Milênio deu muito pano para a manga.

Pregações, grupos de apoio, comunidades para reconstrução do mundo após o desastre, grupos de pessoas que passariam a virada - e o último momento - juntos, feirões para a venda de itens como moedas de ouro e fogões à lenha, estoque de armas, munições e comida e até a publicação de livros-guia de sobrevivência ao evento.

Aliás, neste artigo pode-se ver uma investigação que aponta que alguns profetas e líderes religiosos lucraram milhões de dólares com a venda dos chamados kits de sobrevivência.

E não foram somente as pessoas de mente fraca ou as empresas temendo perdas financeiras recorde que se desesperaram. Governos de diversos países montaram comitês especiais de contingência de crise para monitorar anomalias e preparar tanto medidas preventivas como de contenção de danos nas telecomunicações ou qualquer tipo de serviço de urgência. Até mesmo grupos internacionais de cooperação foram criados e financiados pelo Banco Mundial.

Embora a onda de pânico generalizada tenha se instaurado, graças às atualizações e à popularização dos computadores ter se dado somente nos anos 90 (quando os sistemas já estavam mais inteligentes e preparados a uma falha dos anos 60) as consequências foram infinitamente menores do que se temia. 

Mas como os riscos de perda eram enormes, nem mesmo a virada do ano e o relativo "nada" que ocorreu foi capaz de amenizar os ânimos. Acreditava-se que cerca de apensa 10% dos problemas iriam desencadear-se entre os dias 01 e 15 de janeiro de 2000. O restante viria no decorrer dos dias e meses, dificultando a identificação e controle de panes nos sistemas.

Pequenos problemas foram notados, como as 10 mil máquinas de cartão de crédito do HSBC que pararam de processar pedidos entre 28 de dezembro e 1º de janeiro, um reator de uma usina nuclear no Japão, onde o monitoramento de radiação foi comprometido à meia noite da virada (sem problemas para as pessoas), as máquinas de tickets de ônibus que pararam de validar as transações na Austrália, entre outras coisas inofensivas e até cômicas (o relógio que marca o horário oficial dos Estados Unidos marcando 01 de janeiro de 19100).

A parte mais tensa de tudo isso foi quando o exército americano detectou o lançamento de 3 mísseis russos que pegou a todos desprevenidos. Mas rapidamente o governo russo informou que eles tinham lançados conscientemente e faziam parte do conflito que ocorria contra os rebeldes da Chechênia.

Valeu a pena?

Passado a tormenta, hoje especula-se até um certo alarmismo proposital por parte das empresas de segurança digital (imagine você o quanto um banco pagou para ter a garantia de que seus dados não seriam alterados). Estima-se que os gastos de prevenção (incluindo gastos menores com reparos de danos após a virada) relativos ao Bug do milênio tenham ficado entre 300 e 600 bilhões de dólares.

Os analistas dividiram-se entre 2 grupos: Os que acharam o Bug do Milênio real e aqueles que acham que ele não passou de um embuste.

Mas antes de ver o posicionamento de cada um dos grupos, vamos ver como o Brasil se posicionou nessa história toda. Com vocês uma reportagem veiculado no Fantástico do domingo de 26 de dezembro de 1999 e a nossa "Comissão de Controle de Bug":

Bug real

Aqueles que pregam este discurso valem-se como argumento das consequências mínimas que o evento acarretou. Segundo os especialistas de segurança da época os riscos eram sim reais e alarmantes e que o pior só não aconteceu "porque o mundo passou pelo maior desafio de gerenciamento dos últimos 50 anos". 

Eles alegam até que (e com muita coerência) os danos do ataque terrorista de 11 de setembro foram mitigados por conta dos altos investimentos feitos para suportar o bug computacional alguns anos atrás.

Sem estas medidas adotadas no final dos anos 90 o pânico poderia ter sido muito maior naquela trágica manhã, já que a cidade de Nova Iorque não teria modernizado sua infraestrutura (metrô, telefonia e geração de energia), as empresas não teriam seus planos de contingência revisados e prontos para uma emergência, o sistema financeiro não teria se mantido sólido e os danos ao maior centro financeiro do planeta teriam sido amplamente maiores e incalculáveis. 

Falso positivo

Mas se tem o pessoal que acha tudo verdadeiro, claro que tem o pessoal que acha que essa história toda não passou de um exagero. E eles também têm boas provas de que estavam certos.

Como prova disso eles citam os casos de países como a Itália e a Coreia do Sul, que, ao contrário de dos EUA, não investiram quase nada em prevenção de danos e obtiveram as mesmas consequências quase nulas daquele que gastou horrores.

Outro apontamento é de que com o medo e tensão no dia da virada o serviço de apoio aos pequenos comércios dos EUA esperava receber milhares de ligações pedindo ajuda. O que ocorreu, na verdade, foram 40 telefonemas... na primeira semana inteirinha de janeiro. A mesma média das semanas anteriores e nenhum deles era algo crítico. Ou seja: nada de novo.

E o futuro?

Desse mal não sofremos mais, certo? Mais ou menos... pois temos um novo bug a caminho, e com data marcada: Precisamente às 3 horas da manhã, 14 minutos e 8 segundos do dia 19 de janeiro de 2038 (no horário de Brasília) os relógios dos pcs voltarão para 13 de dezembro de 1901.

O problema é mais complexo e se dá pelo seguinte motivo: Por conta de um outro padrão dos anos 70, o tempo é contado nas máquinas através dos segundos passados desde 01 de janeiro de 1970. Essa conta ininterrupta vem acontecendo desde então. A cada 1 segundo o valor é incrementado em 1 unidade, e assim, após uma conversão em questão de milésimos, a máquina sabe qual a hora exata daquele segundo. No segundo seguinte ela repete o processo, depois de novo, depois de novo e assim tem feito há mais de 45 anos.

O novo bug decorre da maioria dos programas ter sido escrito na linguagem C, uma linguagem que possui uma biblioteca de tempo que utiliza um inteiro de 32 bits unsigned para armazenar a contagem dos segundos. Sem explicações mais longas e cansativas vou resumir: o valor máximo que um inteiro de 32 bits pode armazenar é 2.147.483.647. Transforme cada 1 destes em 1 segundo e você cairá no profético instante de 2038 citado acima.

Assim, se nenhuma solução for pensada até lá, os computadores voltarão a 1901 ou 1970, dependendo de como teve seu código escrito. Para resolver esse não é tão simples, já que apenas alterar tudo abruptamente para 64 bits poderia piorar as coisas. O que está sendo feito então é uma migração lenta e gradual onde os novos sistemas são implementados já neste novo formato. Espera-se que até 2038 tudo esteja migrado.

E depois que tudo estiver em 64 bits, aí sim estaremos tranquilos, pois o novo sistema dá um "certo prazo" para o próximo corte, mais exatamente 290 bilhões de anos. Sendo assim, até 4 de dezembro do ano de 292.277.206.596 estaremos tranquilos.

Ahhh e o pessoal ficou tão ressabiado que já estão prevendo o que fazer quando vier o bug do ano 10000 onde todos os anos passarão a ter 5 dígitos e tudo até hoje está sendo gravado com somente 4. Sério. Clique aqui para ler a resolução.