O RPi sofrerá com o bug do Y2K38?

Por curiosidade, o que acontecerá com os RPis Modelo A e B em 19 de janeiro de 2038 em 3:14:07 GMT? Eles são afetados pelo bug do Y2K38 ?

hardware system-clock bugs DaGhostman Dimitrov
fonte

Quantos você espera que ainda esteja sendo executado?

Thorbjørn Ravn Andersen

@ ThorbjørnRavnAndersen para ser honesto eu acredito que o RPI tem grande futuro e haverá muitos deles ainda em funcionamento (eventualmente, modelos C ou superior mas ..)

DaGhostman Dimitrov

Nesse caso, acerte o relógio e veja.

Thorbjørn Ravn Andersen

Não pensei nisso ..: D

DaGhostman Dimitrov

Qualquer que seja o futuro do pi, as chances são de que nem ele ainda esteja usando um processador de 32 bits em 25 anos. De acordo com a Wikipedia, os sistemas de 64 bits usam um de 64 bits time_t, transformando isso no problema Y292G , que nem nós nem o sol viveremos para ver.

goldilocks

Respostas:

Sim.

Aqui está a saída de uma sessão SSH para o meu Pi executando o OpenELEC.

Ele trava após atingir o Y2K38. Não apenas a própria sessão SSH para de responder, mas o OpenELEC também congela.

Espero (e espero!) Que até 2038 uma correção seja lançada.

^{Isso ou sua pergunta receberá muitos votos em 24 anos.}

insira a descrição da imagem aqui

Aquele cara brasileiro
fonte

Estou surpreso que você tenha conseguido abrir uma sessão SSH com uma máquina com uma data tão descontrolada. 1 por realmente tentar.

einnocent

@einnocent Por que eu não seria capaz? Existe algum tipo de comparação de tempo nas especificações de handshake do SSH que o impediria? Além disso, mudei o tempo após o estabelecimento da conexão. Além disso, o relógio Pi já estava errado de qualquer maneira (há alguns meses, anos, não me lembro): P

Aquele cara brasileiro

Alterando a pré-conexão da hora, entendo que grandes diferenças nos horários podem causar problemas com alguns handshakes de segurança, embora eu não conheça o SSH em particular. Com uma alteração pós-conexão, pude imaginar o SSH subitamente surtando ao descobrir que ele tinha uma conexão aberta por 34 anos. Suponho que haja uma pequena (mas diferente de zero) chance de o SSH simplesmente encerrar a conexão naquele momento mágico. Mas realmente estou convencido com a sua resposta :)

einnocent

@einnocent Não me ocorreu que o SSH pudesse pensar que estava "aberto por 24 anos" e travou. Vou tentar novamente com, digamos, 22 anos. Mas acho que não é a causa, porque fica exatamente ao atingir Y2K38

aquele brasileiro

Na verdade, o Raspberry Pi (hardware) vai ficar bem. Ele não contém um RTC, portanto, dependerá de qual sistema operacional você usar.

Mas o IIRC, toda a versão de 32 bits do Linux, tem esse problema. Algum tempo atrás (aproximadamente 10 anos), Linus disse que não era interessante em consertar isso em plataformas de 32 bits e todas as plataformas Linux de 64 bits na época tinham 64 bits time_t. Ele pode ter mudado de idéia desde então, é claro. O melhor link para isso que encontro é http://permalink.gmane.org/gmane.linux.kernel/1184914 - que não é o mesmo, mas expressa uma intenção semelhante.

Não será algo particularmente difícil de mudar, mas forçaria uma alteração nas ABIs do kernel. O que é um problema em si.

Mas, o RiscOs usa um tempo de 40 bits (centisegundos), mas com uma época diferente. ( https://www.riscosopen.org/wiki/documentation/show/OS_Word%2014_3 ) - Eu faço isso em algum momento em 2318 - [calc era: 1970 + ((2 ^ 40) / 100) / / 60 * 60 * 24 * 365,25)]

O Android, é claro, usa o kernel do Linux. E tenho certeza que perdi outras opções.

rgammans
fonte

Conforme atualmente implementado, o Raspberry Pi sofrerá o destino do bug listado, se nenhuma alteração no software for feita.

A maioria das máquinas modernas está dando um salto para os processadores de 64 bits, mas não me surpreenderia ainda ver os processadores de 32 bits mainstream nesse ponto. Existem soluções de software que poderiam e terão que resolver o problema.

Parece-me que a correção mais provável seria atualizar o horário da Epoch para começar em algo como 1º de janeiro de 2000. Embora isso não atrasasse o bug, certamente o redefiniria no futuro próximo.

Jacobm001
fonte