проблема 2038 года

2 tazhate
здесь нет оффтопа

На нынешней 32х битной винде time_t давно стал 64 битным. А вот 32х битных Unixов через 25 лет скорее всего вообще не останется. да и если останутся, ничто не мешает сделать заранее тип 64х битным.

Будет ли кого-то это волновать - через 25-то лет? Ж;-)

хм, а с zip`ами старыми что делать?

поживём-увидим :)

Все просто, если у файла расширение zip, и заголовок старого формата, то будет считаться что он явно создан до 2038 года :-)

32-х битных приложениях

2038

32-битные приложения и сейчас-то только у некрофилов и виндузятников. А уже через столько лет их вообще не останется.

А если найду?

на контроллерах всяких остались даже 8 бит

Контроллеры другое дело. Там и время наверное иначе хранится.

А как же компьютеры На Которых Держится Интернет (и весь остальной мир, т.е. к которым черепаха примотана скотчем)

Отлепить черепаху, как вариант.

И на чем она тогда стоять будет?

дожить бы

На костыле. А костыль будет на воздушной подушке, да.

бывает и 4 битные

в 2038 найдутся маргиналы на x86 дистрибутивах, которые форкнут все, что нужно, подкостыляв время до 64 битного time_t лишь бы «не ставить сырой amd64»

ты еще скажи к155ла3 не плод моего воображения

К тому времени дебиан 10 как раз выйдет из тестинга, наверное)

Уже сейчас все новые процессоры для настольных компьютеров - 64-битные. Будет ли кого-то волновать через 25 лет тот факт, что во многих юниксах, рассчитанных на древнейшие (устаревшие уже сейчас), к тому времени уже на 100% вышедшие из употребления 32-битные процессоры, имелась некая проблема 2038 года?

Либо формат доработают, либо он умрет. Оба варианта хороши.

Для юниксов используются обычно 32-битные контроллеры. И для контроллеров гораздо безболезненнее сломать ABI, чем для настольных компьютеров.

x64 не нужен, адресация большего объема памяти как то слабо тянет на революцию, тебе так не кажется? больше разницы вообще никакой нет. Более чем уверен, что x64 это какой то очень неудачный промежуточный этап перед чем то действительно значимым.

не думаю что к тому времени будут активно пользоваться 32-битными ОС

Более чем уверен, что x64 это какой то очень неудачный промежуточный этап перед чем то действительно значимым.

Прочитай про итаниумы.

А что конкретно? Общие сведения как в википедии и так известны. Зионы же кроме серверов никуда больше не годятся, да и в торжество одного интела слабо верится.

перед чем то действительно значимым

http://lurkmore.to/128_bit ?

Викинул свою ac100 в 2037. Больше 32битных компов не имею.

Регистры забыл. А вообще да, все должны перелезать на армы.

Извини, но машину времени я еще не изобрел.

Та в общем то всем плевать на регистры, быстрее он от этого работать не будет, уже сколько времени наблюдаю одинаковую картину. Под армы еще софт надо написать, тогда может кто и перелезет.

Будет-не будет — дело второе. Я просто уже давно не видел x86-систем, ну умерли они. Очень печально, что в процессоре приходится тащить кусок старой архитектуры ради совместимости с проприетарщиной, которая не осилила собраться под amd64.

Нет

// пишу этот пост с самопайки на к155* серии

Недавно сталкивался с тем, что в MySQL поле типа TIMESTAMP 32-битное, соответственно подвержено этой проблеме.

Будет ли проблема со временем/сбои в 32-х битных приложениях в 2038?

да. Будет. Если конечно приложения останутся. В том смысле, что не каждое приложение этому подвергнуто - если в приложении время чисто для индикации, то проблемы нет. Проблема есть только если код принимает решение, в зависимости от того, что было до, а что после (man причинно-следственная связь). Когда время перекинется через ноль, то что было ПОСЛЕ, программа будет считать РАНЬШЕ. Обычно это не важно.

хм, а с zip`ами старыми что делать?

ну они будут плакать, что дескать «прикинь одмин! я файл из будущего извлекаю!». Сейчас такое с tar'ом бывает, если часы на каком-то сервере отстают - он принимает файл с другого сервера, а файл из будущего! Это warning.

Я просто уже давно не видел x86-систем, ну умерли они

64х битная MySQL так до сих пор 32х битный INTEGER и TIMESTAMP юзает. Т.ч. битность тут не причём.

Недавно сталкивался с тем, что в MySQL поле типа TIMESTAMP 32-битное

дык потому-что 32 бита unix age это стандарт такой, и от архитектуры он не зависит. В 16и битной тоже самое было.

Хм, интересненько. Впрочем, я думаю до 2038 успеют выпустить новую версию :)

да, ещё программы бекапов сломаются, ибо ВНЕЗАПНО ВСЁ станет старым, и незабекапленным (последний бекап был во время 123, а все файлы созданы во время ~4294967000).

Т.е. вангую петабайтный трафик от кучи серверов с аптаймом >25 лет. Они внезапно будут ВСЁ бекапить, до чего дотянуться.

Зионы же кроме серверов никуда больше не годятся

То-то их в макпро по две штуки ставят.

То-то их в макпро по две штуки ставят.

А сами макпро юзают две штуки пользователей :)

Где есть список софта с версиями, который подвержен проблеме 2038?

Викинул свою ac100 в 2037.

Макскому ключи от машины времени верни!

Будет ли проблема со временем/сбои в 32-х битных приложениях в 2038?

Нет. Будет проблема с качеством пороха в патронах и количеством плутония и в собранной на поверхности еде.

32-битные приложения и сейчас-то только у некрофилов и виндузятников.

А как насчет Skype? Adobe Reader? Wine?

Я так и сказал: у некрофилов и виндузятников.

http://www.youtube.com/watch?v=D6IexV6i5Ho

32-битные приложения и сейчас-то только у некрофилов

Во заявы... А ничего, что не все P4 x86-64 поддерживают ? ;-)
Это вот model name : Intel(R) Pentium(R) 4 CPU 2.40GHz выкидывать уже ? :-)

У меня core 2 duo 2.6GHz, и его честно говоря давно пора выкидывать. Просто на десктопе можно выжить и с таким хламом, если особо не напрягать систему.