Czy RPi będzie cierpieć z powodu błędu Y2K38?

Z ciekawości, co stanie się z RPis Model A i B 19 stycznia 2038 o 03:14:07 GMT? Czy dotyczy ich błąd Y2K38 ?

hardware system-clock bugs DaGhostman Dimitrov
źródło

Ile spodziewasz się wtedy jeszcze uruchomić?

Thorbjørn Ravn Andersen

@ ThorbjørnRavnAndersen, szczerze mówiąc, wierzę, że RPi ma wielką przyszłość i będzie wiele z nich nadal działa (ostatecznie modele C lub większe, ale ..)

DaGhostman Dimitrov

W takim przypadku ustaw zegar i zobacz.

Thorbjørn Ravn Andersen

Nie myślałem o tym ..: D

DaGhostman Dimitrov

Niezależnie od tego, jaka jest przyszłość pi, są szanse, że nic, ani nic innego nie będzie nadal używać 32-bitowego procesora za 25 lat. Zgodnie z wikipedią, systemy 64-bitowe używają wersji 64-bitowej time_t, zamieniając to w problem Y292G , którego ani my, ani słońce nie przeżyjemy.

Złotowłosa

Odpowiedzi:

Tak.

Oto wynik sesji SSH dla mojego Pi z OpenELEC.

Zawiesza się po osiągnięciu Y2K38. Nie tylko sama sesja SSH przestaje odpowiadać, ale także zawiesza się OpenELEC.

Oczekuję (i mam nadzieję!), Że do 2038 r. Zostanie wydana poprawka.

^{To lub twoje pytanie zyska wiele pozytywnych opinii za 24 lata.}

wprowadź opis zdjęcia tutaj

Ten brazylijski facet
źródło

Dziwię się, że udało ci się otworzyć sesję SSH na komputerze z tak szaloną datą. +1 za faktyczne wypróbowanie tego.

einnocent

@einnocent Dlaczego miałbym nie być w stanie? Czy istnieje jakieś porównanie czasu w specyfikacjach uzgadniania SSH, które mogłoby temu zapobiec? Poza tym zmieniłem czas po ustanowieniu połączenia. Poza tym i tak zegar Pi był już niepoprawny (o kilka miesięcy, lat, nie pamiętam): P

Ten Brazylijczyk

Zmieniając wstępne połączenie czasu, rozumiem, że duże różnice w czasach zegara mogą powodować problemy z niektórymi uzgadnieniami bezpieczeństwa, chociaż nie wiem w szczególności o SSH. Po zmianie połączenia mogłem sobie wyobrazić, że SSH nagle wariuje, odkrywając, że połączenie jest otwarte przez 34 lata. Przypuszczam, że istnieje niewielka (ale niezerowa) szansa, że SSH po prostu zakończyło połączenie w tym magicznym czasie. Ale naprawdę jestem przekonany twoją odpowiedzią :)

einnocent

@einnocent Nie przyszło mi do głowy, że SSH może pomyśleć, że jest „otwarty przez 24 lata” i zawiesił się. Spróbuję jeszcze raz, powiedzmy, 22 lata. Ale myślę, że to nie jest przyczyna, ponieważ zawiesza się dokładnie po osiągnięciu Y2K38

ten Brazylijczyk

W rzeczywistości Raspberry Pi (sprzęt) będzie w porządku. Nie zawiera RTC, więc będzie zależeć od używanego systemu operacyjnego.

Ale IIRC we wszystkich 32-bitowych wersjach systemu Linux ma ten problem. Jakiś czas temu (około 10 lat) Linus powiedział, że nie jest interesujący w naprawianiu tego na platformach 32-bitowych, a wszystkie 64-bitowe platformy Linux w tym czasie miały 64-bitowy time_t. Oczywiście od tamtej pory mógł się zmienić. Najlepszy link do tego, jaki mogę znaleźć, to http://permalink.gmane.org/gmane.linux.kernel/1184914 - który nie jest taki sam, ale wyraża podobne zamiary.

Zmiana nie będzie szczególnie trudna, ale wymusiłaby zmianę w ABI jądra. Co samo w sobie jest problemem.

Ale RiscOs używa 40-bitowego czasu (centisekundy), ale z inną Epoką. ( https://www.riscosopen.org/wiki/documentation/show/OS_Word%2014_3 ) - Robię to kiedyś gdzieś w 2318 - [obliczono: 1970 + ((2 ^ 40) / 100) / (60 * 60 * 24 * 365.25)]

Android oczywiście używa jądra Linux. I jestem pewien, że przegapiłem inne opcje.

rgammany
źródło

W tej chwili Raspberry Pi spotka los wymienionego błędu, jeśli nie zostaną wprowadzone żadne zmiany w oprogramowaniu.

Większość współczesnych maszyn przeskakuje na procesory 64-bitowe, ale nie byłbym wcale zaskoczony, że wciąż widzę 32-bitowe procesory głównego nurtu. Istnieją rozwiązania programowe, które mogłyby i będą musiały rozwiązać problem.

Wydaje mi się, że najbardziej prawdopodobną poprawką byłaby aktualizacja czasu Epoki, aby rozpocząć od czegoś takiego jak 1 stycznia 2000 r. Chociaż nie opóźni to błędu, z pewnością zresetuje go w najbliższej przyszłości.

Jacobm001
źródło