linux vai parar em 2038????

danniel-lara
(usa Fedora)

Enviado em 10/02/2017 - 16:53h

Será ?
mas acho que é pouca coisa
pois tudo agora é 64Bits
tem muitas empresas já migrando para 64Bits

removido
(usa Nenhuma)

Enviado em 10/02/2017 - 17:18h

O problema do ano 2038 (também conhecido como Y2K38, em referência ao Y2K) é uma falha na representação de datas em computadores, que pode causar erros em alguns programas de computador no ano de 2038.

O problema afeta os programas que utilizam a representação de tempo POSIX, em que a data é calculada através do número de segundos (ignorando os segundos bissextos) desde 1 de janeiro de 1970[1]. Esta representação é padrão nos sistemas operacionais do tipo Unix e afeta a maioria dos sistemas, pois grande parte deste software foi desenvolvido na linguagem C. Na maioria dos sistemas de 32 bits, o tipo de dados time t, utilizado para armazenar esta contagem de segundos, é um inteiro de 32 bits do tipo signed (considera o sinal). O último registro de tempo que pode ser representado por este formato, seguindo o padrão POSIX, é 03:14:07 na terça-feira 19 de janeiro de 2038 (UTC). Após este momento a data será representada por um número decimal negativo que, dependendo da implementação, corresponderá ao ano 1970 ou 1901. Este valor para a data corrente certamente resultará em erros de cálculo e de funcionamento na maior parte dos programas em execução pelo sistema.

Solução[editar | editar código-fonte]
Não há maneira simples de resolver este problema para os sistemas existentes. Alterar a definição do time_t para 64 bits pode quebrar a compatibilidade binária de softwares, dados persistidos e de qualquer sistema que manipule datas representadas no formato binário. Alterar o time_t para um inteiro de 32 bits unsigned (não considera o sinal) pode alterar vários programas que trabalham com diferenças de tempo.

A maioria dos sistemas que suportam a arquitetura de 64 bits já suportam o time_t de 64 bits. A migração para esta arquitetura já está em andamento e muitos esperam que ela esteja completa até 2038. Porém, milhões de sistemas de 32 bits foram instalados até o ano de 2006, muitos em sistemas embarcados, e é muito incerto se eles serão totalmente substituídos até 2038. Apesar de, normalmente, os sistemas serem atualizados num prazo de 18-24 meses, os sistemas embarcados podem operar sem alterações por toda a vida do sistema que controlam. A utilização do time_t de 32 bits foi codificada em alguns formatos de arquivo, como o ZIP, o que significa que o problema pode permanecer por um longo período após a expiração da vida útil das máquinas envolvidas.

A utilização de valores de 64 bits introduz um novo "corte" na data em aproximadamente 290 bilhões de anos, num domingo em 4 de dezembro de 292.277.026.596[2]. Claramente este problema não é uma questão imediata.

wikipedia

Mauriciodez
(usa Debian)

Enviado em 10/02/2017 - 18:37h

na moral ... esse é um dos bugs mais idiotas que já ouvi falar ... eu explico ... todos nós já ouvimos falar em ábaco certo ??? Levando em consideração que só existem 28 calendários ... vc tem 885.427.200 ( contei com se só tivesse anos bissexto ). muito inferior aos 2.147.483.647 de capacidade dos 32bits ... então se só levarmos em conta só 12 anos, a gente teria uma contagem de 283.824.000s ( 9 anos comum ) + 94.867.200s ( 3 anos Bissexto ) = 378.691.200s ... então a cada 12 anos somaria aos 1970 e zeraria o relógio para mais 12 anos !!! ia ter 32 bit pra dar com o pau !!!

será que que fez a parada não pensou em uma sólução tão simples ??? ou pensou e previu que até 2038 não existiria mais 32 bit ???
_______________________________________________________________
" Nem sempre é amigo aquele que te tira do buraco !!! ( Saddam Hussein )"

ricardogroetaers
(usa Linux Mint)

Enviado em 13/02/2017 - 00:19h

Na época do bug do ano 2.000 a BIOS de muitos computadores, inclusive o meu, não suportava ano de 4 dígitos. Na época foram disponibilizadas várias correções por software. Alguns eram um programinha que era lançado pelo arquivo "autoexec.bat" durante a carga do sistema operacional. Eu usava um programinha que era gravado direto no setor de boot e era carregado antes mesmo do sistema operacional. Problema resolvido até trocar o computador.

Até 2038 o problema já estará resolvido.

Para mais informações ver:
https://pt.wikipedia.org/wiki/Problema_do_ano_2038
https://pt.wikipedia.org/wiki/Problema_do_ano_2000

NAZINHO
(usa FreeBSD)

Enviado em 05/07/2017 - 14:11h

Argh!

https://en.wikipedia.org/wiki/Year_2038_problem#Vulnerable_systems

Sistemas embarcados não podem simplesmente ser substituídos, eles foram feitos para funcionarem por muito tempo (muito mesmo). Tomem como exemplo o sistema de posicionamento de um submarino: Provavelmente ele funciona com algum microkernel em um microcontrolador de 8-bits com uma timestamp (time_t) de 32-bits, não dá para simplesmente trocar de sistema, isso implica em uma série de problemas. Outro exemplo mais comum: imaginem um servidor NTP que fornece ajustes monotônicos a uma rede bancária. Qualquer downtime representa uma perda considerável e esse tipo de transição não se faz de um dia para o outro considerando todos os fatores do mundo real. Poderia citar outros exemplos também como por exemplo equipamentos biomédicos (onde a quantidade de recursos é extremamente limitada e qualquer falha de operação é fatal), sistemas aéreos, controles automotivos, sistemas bancários etc.

Além disso a decisão dos desenvolvedores do Linux de simplesmente ignorar o problema não é aceitável pois força a mudança por parte de usuários críticos, o que não é viável em condições específicas (embarcados em geral).

Os únicos sistemas UNIX que fizeram a mudança até então são NetBSD e OpenBSD.

Não é um problema trivial, é inerente a API usada nos sistemas afetados.

Qual solução vocês sugerem então? Guerras nucleares?

--Referências posteriores--

https://msdn.microsoft.com/en-us/library/aa915351
http://www.ddvtechnologies.com/index.php/latest-news/138-y2038-y2042-are-business-risks
https://y2038.com/faqwd/what-64-bit-cores-are-available-for-embedded-systems/

albfneto
(usa openSUSE)

Enviado em 05/07/2017 - 14:59h

Olha, acho bem difícil.... Tecnologia muda muito,,,, já quase não tem 32 Bits, agora,
quem dirá em 2038... 21 anos.... PC não será mais como hoje, smartphone não será mais como hoje etc....
quem garante que ainda se usará "PC"? podem ser computadores quânticos, biomemórias, multidispositivos, tipo TV, rádio, celular, som e computador num só aparelho.
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Albfneto,
Ribeirão Preto, S.P., Brasil.
Usuário Linux, Linux Counter: #479903.
Distros Favoritas: Sabayon, Gentoo, openSUSE, Mageia e OpenMandriva.

removido
(usa Nenhuma)

Enviado em 05/07/2017 - 18:34h

Até lá você já morreu seu lammer de ...

Freud_Tux
(usa Outra)

Enviado em 05/07/2017 - 18:40h

+ 1

T+

-------------------------------------------------------------------------------------------------------------------------------------------------
Noob: "[...]Sou muito noob ainda usando o terminal, então preciso de ajuda "mastigada", pra operá-lo."
zhushazang: "Sou velho e meus dentes desgastados. Estude linux www.guiafoca.org";

Delusion
(usa Debian)

Enviado em 05/07/2017 - 21:32h

sim; vai parar.
e todos voltaremos a usar windows xp.

Buckminster
(usa Debian)

Enviado em 05/07/2017 - 23:38h

Não, porque o mundo vai acabar em 2019.

http://www.galeriadometeorito.com/2016/01/asteroide-2002-nt7-vai-cair-na-terra-2019.html

E se não acabar em 2019, vai acabar em 2032.

https://oglobo.globo.com/sociedade/ciencia/novo-asteroide-pode-atingir-planeta-em-2032-10430137

removido
(usa Nenhuma)

Enviado em 06/07/2017 - 15:01h

Não!

Pelo que proporam na reforma da previdencia, teria que trabalhar no mínimo 49 anos. Então, iria até 2040. Mas até lá, encontrarão uma forma de adiar isso, tornando ele talvez uma espécie de zombie, que prossiga trabalhando indefinidamente mesmo depois de morto.

Então, relaxa jovem.

valdi
(usa Metamorphose)

Enviado em 18/07/2017 - 18:18h

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk