Будет ли RPi страдать от ошибки Y2K38?


12

Просто из любопытства, что будет с RPis Model A и B 19 января 2038 года в 3:14:07 по Гринвичу? На них влияет ошибка Y2K38 ?


Сколько, вы ожидаете, еще будет работать тогда?
Турбьерн Равн Андерсен

1
@ ThorbjørnRavnAndersen, честно говоря, я верю, что у RPi большое будущее, и многие из них все еще работают (в конце концов, модели C или выше, но ..)
DaGhostman Dimitrov

5
В таком случае установите часы и посмотрите.
Турбьерн Равн Андерсен


1
Каким бы ни было будущее пи, скорее всего, ни он, ни кто-либо еще не будут использовать 32-битный процессор через 25 лет. Согласно википедии, 64-битные системы используют 64-битные time_t, превращая это в проблему Y292G , которую не увидим ни мы, ни солнце.
Златовласка

Ответы:


10

Да.

Вот вывод SSH-сессии для моего Pi с запущенным OpenELEC.

Зависает после достижения Y2K38. Не только сам сеанс SSH перестает отвечать, но и OpenELEC зависает.

Я ожидаю (и надеюсь!), Что к 2038 году будет выпущено исправление.

Это, или ваш вопрос получит много голосов через 24 года.

введите описание изображения здесь


Я удивлен, что вы смогли открыть сессию SSH с машиной с таким безумным свиданием. +1 за то, что попробовал.
einnocent

@einnocent Почему я не смогу? Есть ли какое-либо временное сравнение спецификаций рукопожатия SSH, которое могло бы предотвратить это? Кроме того, я изменил время после установления соединения. Кроме того, часы Пи в любом случае были неправильными (на несколько месяцев, лет, не могу вспомнить): P
Тот бразильский парень

Изменяя предварительное соединение времени, я понимаю, что большие различия во времени могут вызвать проблемы с некоторыми рукопожатиями безопасности, хотя я не знаю о SSH в частности. С изменением пост-соединения я мог представить, что SSH внезапно взбесится, обнаружив, что соединение было открыто в течение 34 лет. Я предполагаю, что есть небольшой (но ненулевой) шанс, что SSH просто разорвал соединение в это волшебное время. Но на самом деле я убежден в вашем ответе :)
einnocent

@einnocent Мне не пришло в голову, что SSH может подумать, что он "открыт в течение 24 лет" и зависать. Я попробую еще раз, скажем, с 22 лет. Но я думаю, что это не причина, потому что это зависает точно при достижении Y2K38
тот бразильский парень

4

На самом деле Raspberry Pi (аппаратное обеспечение) будет в порядке. Он не содержит RTC, поэтому он будет зависеть от того, какую ОС вы используете.

Но IIRC все 32-битные версии Linux имеют эту проблему. Некоторое время назад (10 лет или около того) Линус сказал, что ему неинтересно исправлять это на 32-битных платформах, и на всех 64-битных платформах Linux в то время было 64-битное time_t. Конечно, с тех пор он, возможно, изменил свое мнение. Лучшая ссылка, которую я могу найти, - это http://permalink.gmane.org/gmane.linux.kernel/1184914, которая не совпадает, но выражает аналогичные намерения.

Это не будет особенно сложно изменить, но это вызовет изменение в ABI ядра. Что само по себе является проблемой.

Но RiscO использует 40-битное время (центсекунда), но с другой эпохой. ( https://www.riscosopen.org/wiki/documentation/show/OS_Word%2014_3 ) - я совершаю этот провал где-то в 2318 году - [calc был: 1970 + ((2 ^ 40) / 100) / (60 * 60 * 24 * 365,25)]

Android, конечно, использует ядро ​​Linux. И я уверен, что пропустил другие варианты.


1

Как и в настоящее время реализовано, Raspberry Pi будет страдать от судьбы перечисленной ошибки, если не будет внесено никаких изменений в программное обеспечение.

Большинство современных машин переходят на 64-битные процессоры, но я бы не удивился, увидев в тот момент 32-битные процессоры с мейнстримом. Существуют программные решения, которые могут и должны будут решить проблему.

Мне кажется, что наиболее вероятным решением было бы обновить время Epoch, чтобы оно началось примерно с 1 января 2000 года. Хотя это не задержит ошибку, она наверняка сбросит ее в обозримом будущем.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.