LINUX.ORG.RU
ФорумTalks

18 января 2038 года


0

0

http://www.ibm.com/developerworks/linux/library/l-ext4/
Вычитал отсюда, что ext4 поддерживает timestamp до 25 апреля 2514 года
//для тру:
//Most file systems, including ext3, include timestamp data that is accurate to a second. Ext4 extends the accuracy of this data to a nanosecond. Some sources also indicate that the ext4 timestamps support dates through April 25, 2514, versus January 18, 2038, for ext3.

А правда, что произойдёт, когда наступит магический 2038 год? Винды со своими фатами явно полетят... Да и не думаю, что нтфс рассчитан на тот год. Не получится ли так, что экст4 будет единственной фс, могущей пережить "конец часов"? :)

anonymous

> Винды со своими фатами явно полетят...

у винды время хранит как как количество дней с 31 декабря 1899 года (вроде) в целой части, и часть дня в дробной, так что винды не сдохнут в 2038 году. это вообще проблемы только unix-систем, т.к. в тот момент переполнится 32-битный unix-time.

а вот что будет происходить с 32-битными unix-системами, можно проверить и сейчас.. по моему опыту, около десятка прог стали при переходе с 2038 в прошлое страшно жрать проц и в итоге пришлось ребутнуться :(

Adjkru ★★★★★
()

>Ext4 extends the accuracy of this data to a nanosecond

осталась самая малость - научить Линукс "видеть" наносекунды

>А правда, что произойдёт, когда наступит магический 2038 год? Винды со своими фатами явно полетят...

с какой стати? Только потому что это FAT?

seiken ★★★★★
()

Так и представил. Идет 2037 год. Майкрософт решает продлить продажи windows xp еще на пол года, энтузиастам удалось запустить firefox 43.5 на windows 98, ext25 научилась восстанавливать удаленные файлы с помощью лоровской машины времени...

anonymous
()
Ответ на: комментарий от anonymous

> лоровской машины времени...

неужели к тому времени лор откроет её исходники?

Adjkru ★★★★★
()

Да не паникуйте, мы тут в 38 году давно на 128 битниках сидим и проблемы археониксов из 00 нас мало колышут, другое дело что уран кончается и скоро электричество отключится, придется на заправочный пункт сбегать на новой сборкой, ну пока линуксойды 08 года!

anonymous
()
Ответ на: комментарий от Adjkru

>Most operating systems for 64-bit architectures already use 64-bit integers in their time_t. The move to these architectures is already underway and many expect it to be complete before 2038.

seiken ★★★★★
()
Ответ на: комментарий от anonymous

Давай быстро назад, в бункер, радиоактивное облако идёт а под ним, по данным разведки, отряд терминаторов. И машину времени не забудь.

anonymous
()
Ответ на: комментарий от anonymous

Как там борьба с быдлом и быдлокодом у вас продвигается?

balodja ★★★
()
Ответ на: комментарий от seiken

> Most operating systems for 64-bit architectures already use 64-bit integers in their time_t

это представление в основной памяти, а ведь есть еще случаи когда данные хранятся во внешней памяти или передаются по сети. так что просто переходом на 64bit системы вопрос не решить.

anonymous
()

Проблема в том, что вместо универсального решения все просто пытаются сделать дилду побольше. xfs, timestamp@ext4 - яркие примеры.

anonymous
()

Мой дебиан под amd64 пережил 2038 год замечательно

cvs-255 ★★★★★
()
Ответ на: комментарий от seiken

>Most operating systems for 64-bit architectures already use 64-bit integers in their time_t. The move to these architectures is already underway and many expect it to be complete before 2038.

Изменение определения типа time_t на 64 бита нарушит бинарную совместимость программ, существующих хранимых данных и всего другого использующего представление времени в бинарном виде. А приведение time_t в целое без знака может нарушить работу программ, которые вычисляют разницу во времени.

На большинстве операционных систем для 64-битных архитектур уже используется 64-битное представление целого в time_t. Переход на такие архитектуры уже происходит, и некоторые ожидают, что он будет завершён к 2038 году.

Тем не менее сотни тысяч 32-битных систем всё ещё вводятся в строй в 2008 году, в том числе и во встраиваемых системах. Вызывает сомнение, что они все будут заменены к 2038 году. Несмотря на то, что современные компьютерные системы могут модернизироваться раз в 18-24 месяцев, встроенные компьютеры могут действовать без модернизации весь срок, который работают системы, ими управляемые. Например, компьютеры управления процессами модели IBM 1800, выпуск которых был начат в 1965 году, всё ещё использовались на одной из атомных станций в Канаде в 2006 году.

В дополнение к этому, 32-битный формат time_t также включён в спецификации форматов файлов, таких как повсеместно распространённый архивный формат ZIP. Формат файла может существовать в течение времени, за которое сменятся многие поколения компьютеров, а это означает, что Проблема 2038 останется актуальной.

eugine_kosenko ★★★
()
Ответ на: комментарий от eugine_kosenko

И потом,

Введение 64-битного формата вносит новую дату «закольцевания» через примерно 290 миллиардов лет, в 15:30:08 UTC в воскресенье, 4 декабря 292 277 026 596 года. Но эта проблема на данный момент не считается срочной.

eugine_kosenko ★★★
()

ха-ха-ха-ха, 19 января 2038 дата смерти лялега. Хотя сдается, что он сдохнет раньше.

anonymous
()
Ответ на: комментарий от eugine_kosenko

Угу не считается. Сидим тут, весь софт переписывает из за вашей безалаберности. Жалко было пару килобайт под время выделить что ли?! У вас же вроде сейчас порядка сотни гигов оперативка? Или это в 2020, не помню, шустрые вы тут все, ещё в пределы не упёрлись.

anonymous
()
Ответ на: комментарий от anonymous

не, лялех сдохнет лет через 30, когда кванты дешёвыми станут. там уже другие принципы будут, курите сингулярити.

anonymous
()
Ответ на: комментарий от eugine_kosenko

> Но эта проблема на данный момент не считается срочной.

:)

h8 ★★★
()
Ответ на: комментарий от eugine_kosenko

Я вот попробовал установить эту дату

Втр Дек 4 00:00:25 MSK 219250468

sizeof(time_t) = 8

cvs-255 ★★★★★
()

/* вспоминает проблему 2000 года.... проблему 1900 года */ проблему... проблему...

Вах.. ну может к 38 году мы одновим парк компьютеров

MiklerGM ★★
()
Ответ на: комментарий от MiklerGM

Линукс не дотянет до 2038 года, а сдохнет раньше от размера ядра в 100 Гб. Так что неочем беспокоится.

fdn
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.