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

apocalipseEm pra­ti­ca­mente todas as cul­tu­ras existe o con­ceito de “fim dos dias”, um momento em que a huma­ni­dade — como a conhe­ce­mos — che­gará ao fim por inter­mé­dio de algum evento catas­tró­fico e de con­seqüên­cias ter­rí­veis. O sen­ti­mento de fim, embora sem­pre evi­te­mos pen­sar nele dire­ta­mente, está pre­sente no nosso sub­cons­ci­ente e povoa o ima­gi­ná­rio do homem desde que aban­do­na­mos as caver­nas e nos aven­tu­ra­mos mundo afora.

Ten­tar pre­ver a che­gada do fim tam­bém tem fas­ci­nado e feito estre­me­cer as pes­soas ao longo dos sécu­los. Diver­sas datas apo­ca­líp­ti­cas já foram decre­ta­das por reli­gi­o­sos, mís­ti­cos, mági­cos, pen­sa­do­res e adi­vi­nhos. Sem citar os casos medi­e­vais, onde pra­ti­ca­mente toda data com um sig­ni­fi­cado popu­lar era pre­texto para o fim do mundo.

A civi­li­za­ção evo­luiu, mas o medo, que é um sen­ti­mento ins­tin­tivo, não faz dis­tin­ção de tec­no­lo­gia ou de era. Já em 1910, quando os seres huma­nos come­ça­vam a gozar de con­si­de­rá­veis faci­li­da­des tra­zi­das pela tec­no­lo­gia, o mesmo medo pri­mi­tivo tomava conta de popu­la­ções intei­ras: o pla­neta Terra pas­sa­ria exa­ta­mente pelo ras­tro do cometa Hal­ley e os gases vene­no­sos flu­tu­ando pela atmos­fera iriam pôr fim à exis­tên­cia de qual­quer coisa que res­pi­rasse. Houve uma explo­são na venda de más­ca­ras que pro­me­tiam fil­trar o ar e mais uma vez apren­de­mos que, em tem­pos de crise, sem­pre é pos­sí­vel fatu­rar alto, mesmo que seja em cima da igno­rân­cia alheia.

O fim do mundo tam­bém estava pre­visto para o ano de 1999 e o pró­ximo, segundo os pes­si­mis­tas, vai ser em 2012… Se você esti­ver lendo esse artigo em 2013, é claro, sig­ni­fica que o mundo con­ti­nua firme e forte (com uma ou outra guer­ri­nha, doen­ças, desi­gual­dade social e sogras, mas con­ti­nua inteiro).

Atu­al­mente as nos­sas mai­o­res pre­o­cu­pa­ções têm pouco a ver com maus espí­ri­tos e ras­tros de cometa. Vive­mos num mundo quase total­mente infor­ma­ti­zado mas tive­mos o “nosso” pri­meiro fim do mundo anun­ci­ado para 1999, quando a ame­aça cha­mada “Bug do Milê­nio” mos­trou que o mundo infor­ma­ti­zado tem um cal­ca­nhar de Aquiles.

O nosso cal­ca­nhar de Aqui­les vinha de um pro­blema her­dado de códi­gos mais anti­gos e que aca­bam pas­sando des­per­ce­bi­dos ao longo dos anos sim­ples­mente por­que mesmo os códi­gos mais anti­gos podem fun­ci­o­nar bem, até que as limi­ta­ções da época em que foram escri­tos come­çam a se trans­for­mar em pro­ble­mas para os dias de hoje.

Os pro­gra­ma­do­res de anti­ga­mente pre­ci­sa­vam lidar com o pro­blema de falta de memó­ria e, de fato, cada byte eco­no­mi­zado pode­ria sig­ni­fi­car uma grande eco­no­mia ou, inclu­sive, se o soft­ware pode­ria ou não ser pro­du­zido. Cada letra (ou número) exi­bido na tela sig­ni­fi­cava 1 byte de gasto; exi­bir uma data como 22 02 1960 que­ria dizer 8 bytes de memó­ria a menos e a solu­ção mais óbvia era cor­tar o “19” do ano, trans­for­mando a data em 22 02 60.

A solu­ção não levava em conta que os códi­gos escri­tos sob esse con­ceito “econô­mico” pode­riam sobre­vi­ver pelos pró­xi­mos 40 anos e che­gar ao dia 31 de dezem­bro de 99.

Basi­ca­mente, sur­giu o risco de que sis­te­mas vitais usando os anos com dois dígi­tos, depois do dia 31/12/99 zeras­sem os reló­gios de volta ao dia 1º de janeiro de 1900.

Con­seqüen­te­mente, taxas ban­cá­rias com 100 anos de juros seriam emi­ti­das, pas­sa­gens aéreas teriam 100 anos de atra­sos e diver­sos softwa­res depen­den­tes de calen­dá­rios enfren­ta­riam problemas.

bugO mundo todo se mobi­li­zou num upgrade pre­ven­tivo que cus­tou milhões de dóla­res e eu ainda me lem­bro da cena mos­trada pela TV, onde logo após a virada do ano de 1999 para 2000, ope­ra­do­res de sis­te­mas come­mo­ra­vam a não mani­fes­ta­ção do bug (pouco se lixando para o fato de ser ano novo).

O Bug do Milê­nio foi der­ro­tado, mas no melhor estilo de um vilão de his­tó­rias em qua­dri­nhos, con­ti­nu­ará a espreita para ata­car numa outra opor­tu­ni­dade. De fato, o pró­ximo pro­blema já tem data e hora mar­ca­dos: 03:14:07, na terça-feira do dia 19 de janeiro de 2038.

Este bug, cha­mado de Bug de 2038 ou Bug do Milê­nio Unix, irá afe­tar todos os sis­te­mas 32 bits que cal­cu­lam suas datas a par­tir da repre­sen­ta­ção POSIX. Na repre­sen­ta­ção de tempo POSIX, todo o tempo é base­ado numa con­ta­gem feita em segun­dos e essa con­ta­gem come­çou no dia 1º de Janeiro de 1970, aumen­tando de segundo em segundo até os dias de hoje.

Se qui­ser des­co­brir a sua “hora UNIX” digite no ter­mi­nal “date +%s”. Essa é a quan­ti­dade de segun­dos que se pas­sa­ram desde 01/01/1970.

O bug de 2038 ocorre por­que a mai­o­ria dos sis­te­mas tipo UNIX de 32 bits é pro­gra­mado em lin­gua­gem C, que trata os valo­res de tempo como núme­ros intei­ros do tipo “sig­ned” (que acei­tam sinais posi­ti­vos e nega­ti­vos). Existe um valor máximo que os núme­ros do tipo “inteiro e com sinal” podem supor­tar 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 segun­dos antes de zerar a contagem.

Alguns sis­te­mas retor­na­rão ao zero (que é 1970) e outros retor­na­rão ao –2.147.483.648 (que é 1901).

O pri­meiro pro­blema sério ocor­rido por causa do bug de 2038 afe­tou os ser­vi­do­res AOL em 12/05/2006. Para garan­tir que nunca ocor­resse time out numa requi­si­ção de banco de dados, os ser­vi­do­res esta­vam pro­gra­ma­dos para tra­ba­lhar com time­outs um bilhão de segun­dos no futuro. Quando esse adi­anto de 1 bilhão de segun­dos atin­giu a data fatí­dica de 2038, os ser­vi­do­res travaram.

A solu­ção, no caso, é a migra­ção para padrões de 64 bits, o que, espera-se, tenha ocor­rido até 2038.

O pró­ximo bug — que deve atin­gir os calen­dá­rios cal­cu­la­dos atra­vés de méto­dos de 64 bits — não é exa­ta­mente uma pre­o­cu­pa­ção ime­di­ata: num domingo, no dia 4 de dezem­bro de 292.277.026.596 às 15:30:08 (UTC), as máqui­nas UNIX de 64 bits tam­bém enfren­ta­rão o Bug de Data.

ADENDO

Mesmo nos dias de hoje ainda há pro­fis­si­o­nais que pre­ci­sam tra­ba­lhar com quan­ti­da­des limi­ta­dís­si­mas de memó­ria e que ficam con­tando cada byte uti­li­zado. Sis­te­mas embar­ca­dos em memó­rias ROM são o melhor exem­plo: medi­do­res de luz e outros meca­nis­mos sim­ples que rodam longe de nos­sos olhos, gra­va­dos em memó­rias não volá­teis e que, mui­tas vezes, car­re­gam códi­gos anti­gos ou bugs poten­ci­ais, esque­ci­dos pelo tempo mas que espe­ram pela opor­tu­ni­dade de se mani­fes­ta­rem. Ainda há, na ver­dade, muito código com mais de 20 anos rodando por aí e ser­vindo de base para softwa­res do nosso dia a dia. O pró­prio Inter­net Explo­rer (pelo menos até a ver­são 6) e o Fire­fox tra­zem peda­ços de código oriun­dos do velho Mosaic, que foi o pri­meiro nave­ga­dor popu­lar da história.

Até 2038 ainda tere­mos bas­tante tempo, mas nenhum espe­ci­a­lista pode garan­tir que a migra­ção atinja 100% das máqui­nas e que o bug de 2038 não terá nenhuma conseqüência.

SEU SISTEMA LINUX 32 BITS VAI BUGAR EM

  • Share/Bookmark

Posts rela­ci­o­na­dos:

  1. Fedora 9 alfa e a arte do futuro desktop
  2. Goo­gle e o apocalipse

This website uses IntenseDebate comments, but they are not currently loaded because either your browser doesn't support JavaScript, or they didn't load fast enough.

10 Responses to “O apocalipse, o bug do milênio e o futuro”


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

  • 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”.

  • Ótimo artigo!

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

  • “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

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

    • 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

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

Leave a Reply