LINUX.ORG.RU
ФорумTalks

Unixtime. 8000 лет спустя.


0

2

Прочёт тут Винджа, «Глубина в небе». Вещь сама по себе неплохая, но заинтересовало знакомство автора с unixtime :)

Фам Нювен несколько лет провел, обучаясь программировать и исследовать. Программирование восходило к началу времен. Как та навозная куча за замком отца. Когда ее промыло ручьем на десять метров в глубь, обнаружились искореженные корпуса машин – летающих машин, как говорили крестьяне, еще от тех великих дней колонизации Канберры. Но та навозная куча была чистой и свежей по сравнению с тем, что лежало в локальной сети «Репризы». Были программы, написанные пять тысяч лет назад, когда человечество еще не покинуло Землю. И самое чудесное (самое ужасное, как говорила Сура) было то, что, в отличие от бесполезных обломков прошлого Канберры, эти программы все еще работали! И через миллион миллионов запутанных нитей наследования многие из старейших программ все еще выполнялись во внутренностях системы Кенг Хо. Например, методы слежения за временем у торговцев. Поправки вносились неимоверно сложно – но на самом дне лежала крошечная программа, которая гоняла счетчик. Секунду за секундой отсчитывала система Кенг Хо с того момента, как нога человек ступила на Луну Старой Земли. Но если приглядеться еще пристальнее… начальный момент был миллионов на сотню секунд позже; момент «ноль» одной из первых компьютерных операционных систем Человечества.

★★★★★
Ответ на: комментарий от Siado

>Это он о недавней новости о полете линукса на луну?

Vemor Vinge A DEEPNESS IN THE SKY 1999

1999



Сомневаюсь. :)

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

>Это он о недавней новости о полете линукса на луну?

Кхм. Высадка на Луну была произведена 20 июля 1969-го года. Во сколько там по Гринвичу - х.з., искать ломает, но до 1 января 1970-го года, соответственно,
php -r 'echo strtotime(«20.07.1969»);'
-14266800 секунд.

14 млн, правда, а не 100млн, но за 8000 лет точное время высадки могли упустить :D Или спутать с первой мягкой посадкой на Луну в 1963-м (соответственно, -123311670 секунд по unixtime).

KRoN73 ★★★★★
() автор топика

> Прочёт тут Винджа, «Глубина в небе». Вещь сама по себе неплохая, но

заинтересовало знакомство автора с unixtime :)


читай вторую часть =) там будет галактический инет и тролли ;-)

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

>читай вторую часть =)

Уже начал. Правда, сказали, что «Глубина в небе» приквел - тогда я обломался. Я предпочитаю читать не в хронологическом порядке, а в порядке написания книг автором :)

...

Ага, глянул - «Пламя» - 1992-й, «Глубина» - 1999-й. Облом. Ну да ладно :)

KRoN73 ★★★★★
() автор топика

8000*365*86400/0xffffffff = 58.74

Вот столько раз он успел обнулиться, так что это давно уже не unix эпоха.

thesame ★★★★
()

>Вещь сама по себе неплохая

Да я бы сказал, более чем. А злодеев уровня Томаса Нау еще поискать.

но заинтересовало знакомство автора с unixtime


Ничего странного:

Vernor Steffen Vinge is a retired San Diego State University (SDSU) Professor of Mathematics, computer scientist, and science fiction author.

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

Пока еще 32-битные системы - скорее правило, чем исключение.

На десктопах - да. Вот только я сомневаюсь, что хоть сколь нибудь заметное число 32-х битных систем хотя бы до 2037-го доживёт :)

А на серверах уже сегодня 64 бита - экзотика:

$ php -r 'echo strtotime("31.12.9999");'
253402203600

Правда, дальше 9999-го года PHP-шный strtotime ошибку выдаёт, просто не верит, что в году может быть больше 4-х цифр :) Ну да за 8000 лет исправят, наверное :D

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

>Пока еще 32-битные системы - скорее правило, чем исключение.

А есть 32-битные системы, где нет 64-битного типа? Речь ведь не о размере int'а идет, а о time_t.

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

По умолчанию в 32-битных системах int 32-битный. И time_t, и offset_t - тоже 32-битные. Поэтому и приходится писать в начале исходника какой-нибудь #define _FILE_OFFSET_BITS 64, чтобы нормально работать с файлами. Эдак, уже стойкая привычка сформируется - в начале каждой программки, работающей с файлами, писать этот define.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от KRoN73

0xffffffff

Это что за антиквариат такой? :)

NetBSD?

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

>По умолчанию в 32-битных системах int 32-битный. И time_t, и offset_t - тоже 32-битные.

Речь идет о том, что это умолчание сравнительно просто изменить. Если не работать с time_t как с 32-битным числом, то простая смена размерности в определение типа и пересборка должны решить проблему.

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

>что мешало аффтарам пыхи запилить time_t? :)

Наверное то, что все целочисленные функции в PHP работают с int'ом. А unix_time там именно целочисленное.

В PHP5.2 ввели отдельный тип, DateTime, который потроха инкапсулирует. Но совсем полноценной эта подсистема стала в 5.3, когда появились всякие DateTime::diff(). С одной стороны, теперь тип инкапсулирован и можно хоть на 16-битной системе полноценный учёт даты реализовать, с другой, PHP 5.3 вышел, когда уже на сервера 64 бита стали нормой :)

...

Но инкапсуляция - всё равно хорошо. Подожду, пока 5.3 станет совсем массовым на быдлохостингах и начну свои методы во фреймворке на более цивильное ядро переписывать :)

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

>PHP 5.3 вышел, когда уже на сервера 64 бита стали нормой :)

Ну, тут можно поспорить о целесообразности 64бит на сервере даже сейчас :)

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

>http://img87.imageshack.us/img87/3056/mysqlmemory.png

Походу, PAE тут не спасёт :)

Тут — не спасет. Собственно СУБД это как раз один из немногих примеров серверных приложений, для которых целесообразна 64-битная ОС. Впрочем, до определенного размера базы/интенсивности работы и тут 64-битный хост избыточен.

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