Logo Hardware.com.br
Core_Dump
Core_Dump General de Pijama Registrado
3.2K Mensagens 111 Curtidas

Novo bug do milênio para 2038?

#1 Por Core_Dump 23/05/2014 - 18:43
Em 2038 computadores e dispositivos eletrônicos podem parar de contar o tempo. A origem do problema está no Unix, sistema operacional criado na década de 1970 que inspirou até o Windows, entre outros sistemas operacionais.O formato de registro de tempo do Unix é bastante limitado. Os programadores optaram por contar o tempo em segundos a partir das 12h no UTC do dia 1º de janeiro de 1970.Para isso, eles usaram um número de 32 bits, com o qual é possível contar até 2.147.483.647 segundos.Somados à hora a partir da qual a contagem começou, esses segundos nos levam ao horário de 3h14 UTC de 19 de janeiro de 2038.

http://www.businessinsider.com/2038-software-32-bit-date-problem-2014-5
sistema operacional bug computadores contar dispositivos milenio unix 2038
ripongao
ripongao Veterano Registrado
755 Mensagens 94 Curtidas
#5 Por ripongao
26/05/2014 - 15:02
era Unix hardsoft

Lembrei agora de um fato curioso pra caramba, antigamente, lá pra 97 ou 98, quando se procurava no google o mesmo mostrava várias informações como por exemplo a data de indexação de determinada página ou cache, minha memória esta ruim, mas o curioso é que já ví páginas indexadas em 1969, claro, alguém deve ter explorado alguma falha qualquer, mas me recordo desse fato.

ahh, quando eu era mais novo eu achava que isso era do bios, o tempo inicial do bios quando resetado, digo, quando se tira a bateria do pc, descarrega o capacitor (clear cmos) e torna a ligar o pc sem configurar nada.
Desliguei-me do fórum. Conta canelada.
TmfeijoMMonroe
TmfeijoMMonr... Cyber Highlander Registrado
13.7K Mensagens 4.2K Curtidas
#6 Por TmfeijoMMonr...
26/05/2014 - 15:18
Boa tarde !

É até interessante . Mas e atualizações e services packs; no caso para sistema/computadores ?


Abraços
A ignorância é a pior inimiga do homem . Não tenho medo de nada; apenas da inveja . E o mundo cada vez melhor !!
Palavras sábias de um hiper profissional do judiciário; perito digital e em psicologia jurídica .
A sua inveja é a velocidade de meu sucesso .
Um coração medroso congela o trabalho . Um coração temerário incendeia qualquer serviço ; arrasando - o .
ripongao
ripongao Veterano Registrado
755 Mensagens 94 Curtidas
#7 Por ripongao
26/05/2014 - 15:25
No caso, uma correção seria duplicar o tamanho usado, pegar a variável que guarda o tempo em segundos de 32 bits e expandí-la para 64 bits, aí sempre que o bloco de 32 bits 'encher'/saturar, o 'vai um' matemático ocorre e o bloco 'mais à esquerda' recebe esta adição, até que um dia o bloco esquerdo também 'enche de uns' aí dá um bziu a não ser que outro bloco seja colocado mais à esquerda.... .
Soluções para o infinito ainda não existem pois o infinito (big numbers) nesse caso seria a quantidade máxima de memória de uma máquina, ou todo o espaço no disco rígido para se guardar o tempo do pseudo infinito.
A solução é simples, basta boa vontade.

Não, não estou por dentro de correções, apenas disse teoricamente.
Desliguei-me do fórum. Conta canelada.
ripongao
ripongao Veterano Registrado
755 Mensagens 94 Curtidas
#10 Por ripongao
26/05/2014 - 15:44
que eu saiba não, é a mesma ideologia, um bloco de tantos bits que guardam contagem de tempo, seja nanosegundos, segundos, ... .

O relógio é uma máquina mais difícil de entender que o computador na minha opinião. Várias bases são usadas; começando de segundos para facilitar, a cada 60 segundos temos 1 minuto, a cada 60 minutos temos 1 hora; a cada 24 horas temos 1 dia; a cada 365 dias temos 1 ano, ... .
Viu, começou da base 60, depois base 60, depois base 24, depois base 365, ..., dificil pra caramba. No pc não, é só binário (base 2) e hexadecimal (base 16), muito mais fácil.
Desliguei-me do fórum. Conta canelada.
foca
foca Highlander Registrado
12.2K Mensagens 1.1K Curtidas
#11 Por foca
26/05/2014 - 16:15
O Windows é baseado no VMS e não no Unix.
Ele só vai dar problema em 2138.
Mas programas baseados na biblioteca padrão C correm o risco de não funcionar, o MySQL por exemplo.
8x AMD-Sony JAGUAR 1.6GHz| 8GB@2.7GHz GDDR5| 18x RADEON@800MHz| Sony BD| Gaikai Cloud
STI Cell 3.2GHz| 256MB@3.2GHz RAMBUS| Nvidia RSX@500MHz| 256MB VGA RAM| Sony BD
Sony EE 295MHZ 128 bits|Sony GS 148MHZ|32MB RDRAM| Sony DVD
http://brunofoca.blog.uol.com.br
12 anos de GDH - Ñ tiro dúvida por MP
N0625
N0625 Super Zumbi Registrado
7.1K Mensagens 785 Curtidas
#12 Por N0625
26/05/2014 - 16:28
foca disse:
O Windows é baseado no VMS e não no Unix.
Ele só vai dar problema em 2138.
Mas programas baseados na biblioteca padrão C correm o risco de não funcionar, o MySQL por exemplo.

Como assim, foca?

Edit.: já encontrei a razão, foca. =)

Marcos FRM disse:
http://lwn.net/Articles/563285/

Ahhh, agora eu entendi o fenômeno que ocorria com um PC antigo que tinha no meu setor de trabalho até os idos de 2007. Era um K6-2 muito valente rodando numa placa-mãe raçuda que usava chipsets da VIA, executando o NT 4 com somente 32 MB de memória por quase 6 anos, uma verdadeira rocha de estabilidade. Bom, um dia resolveram fazer um upgrade nessa máquina. Colocaram mais 64 MB, trocaram o HD PIO 4 de 4 GB e instalaram o Windows 2000. Continuou sendo uma rocha, literalmente. Pesado que só. O bichinho se arrastava, mas se mantinha estável. Pois bem, ocorria um fato que provavelmente era provocado por incompatibilidade ou bug do BIOS. Toda vez que a máquina iniciava o Windows ajustava a data do sistema para 01/01/1601! E a gente só lembrava que tinha que acertar a data por causa de um programa cliente de cadastro de processos que bugava com a discrepância absurda. E o mais engraçado é que o Windows não aceitava ajustar o ano para qualquer coisa abaixo de 1980, mas o sistema conseguia configurar o ano para 1601!

Ah, sim. Essa "brincadeirinha" também bugava o calendário do BIOS. Fiz um teste reiniciando o sistema mantendo o ano de 1601 e entrando no BIOS. Neste, o calendário voltava para o ano da compilação do firmware.

ripongao disse:
que eu saiba não, é a mesma ideologia, um bloco de tantos bits que guardam contagem de tempo, seja nanosegundos, segundos, ... .

O relógio é uma máquina mais difícil de entender que o computador na minha opinião. Várias bases são usadas; começando de segundos para facilitar, a cada 60 segundos temos 1 minuto, a cada 60 minutos temos 1 hora; a cada 24 horas temos 1 dia; a cada 365 dias temos 1 ano, ... .
Viu, começou da base 60, depois base 60, depois base 24, depois base 365, ..., dificil pra caramba. No pc não, é só binário (base 2) e hexadecimal (base 16), muito mais fácil.

Pois é. Falam que o algoritmo usado para operar esses relógios de parede é bastante complexo. Gozado, né? Um circuito que só fica contando segundos.

Mas se o calendário do Unix não considera os segundos bissextos, como ele consegue "saber" quais anos são bissextos desde então?

ripongao
ripongao Veterano Registrado
755 Mensagens 94 Curtidas
#13 Por ripongao
26/05/2014 - 17:15
aí é apenas uma conversão pois o total em segundos já se tem, e o problema é quando a variável que segura esses segundos transborda/estoura com a base pré-estabelecida. No link citado mostra os anos em que se iniciaram a contagem temporal, como por exemplo o Android, que possui uma resolução de 1 ms, e a data base para contagem é 1 de Janeiro de 1970. Somando-se a este ano tantos segundos levando em consideração anos bissextos (analogia a segundos bissextos) pode-se realizar a transformação tranquilamente.

Bom, se deseja saber a verdade posso te contar, mas a sociedade não esta pronta para ela. Se levarmos em consideração os milisegundos e nanosegundos perdidos na conversão estavamos lascados, pois o ano em que vivemos estaria errado.
O que quero falar é que hoje não é 26 de maio de 2014 como olhei no calendário agora, se fosse realizadas correções estaríamos num calendário totalmente diferente, isso tudo por causa das correções que não fizeram do ano bissexto (milisegundos perdidos). E outra, um ano não são 365 dias, e sim 365 dias, tantas horas, tantos minutos, segundos, ... .Hoje estaríamos lá para o ano 2020 mais ou menos. Viu o problema que pode causar na sociedade? Sinistro.
Desliguei-me do fórum. Conta canelada.
N0625
N0625 Super Zumbi Registrado
7.1K Mensagens 785 Curtidas
#14 Por N0625
26/05/2014 - 17:34
ripongao disse:
aí é apenas uma conversão pois o total em segundos já se tem, e o problema é quando a variável que segura esses segundos transborda/estoura com a base pré-estabelecida. No link citado mostra os anos em que se iniciaram a contagem temporal, como por exemplo o Android, que possui uma resolução de 1 ms, e a data base para contagem é 1 de Janeiro de 1970. Somando-se a este ano tantos segundos levando em consideração anos bissextos pode-se realizar a transformação tranquilamente.

Bom, se deseja saber a verdade posso te contar, mas a sociedade não esta pronta para ela. Se levarmos em consideração os milisegundos e nanosegundos perdidos na conversão estavamos lascados, pois o ano em que vivemos estaria errado.
O que quero falar é que hoje não é 26 de maio de 2014 como olhei no calendário agora, se fosse realizadas correções estaríamos num calendário totalmente diferente, isso tudo por causa das correções que não fizeram do ano bissexto (milisegundos perdidos). E outra, um ano não são 365 dias, e sim 365 dias, tantas horas, tantos minutos, segundos, ... .Hoje estaríamos lá para o ano 2020 mais ou menos. Viu o problema que pode causar na sociedade? Sinistro.

Hehe! Abafa o caso. =) Mas, tipo assim... eu também tenho comigo que não estamos no dia 26/05/2014 pelo fato de que na China é um período, em alguns países do Oriente é outro... enfim. Somos sim regidos por um calendário digamos... comercial, civil.

Mas é interessante a abordagem deste tema em termos computacionais. Só gostaria de saber se o $ cal ou a função dia.da.semana das planilhas estão certos quando retornam como sexta-feira o dia da semana que cairá 31/12/9999. o.O

© 1999-2024 Hardware.com.br. Todos os direitos reservados.
Imagem do Modal