Comments 51
Судя по дате я могу с 99% уверенностью сказать что все дело в том что Skype где-то внутри использует обыкновенный Unix time.
Это всего лишь Year 2038 problem eng, rus. Краткий пересказ статьи в википедии: 32х-разрядная дата-время.
Человек узнал про unix time, который хранится в обычном int, я думаю все рады.
14 минут и 8 секунд ;)
Каким образом, один процесс, занявший процессор, может существенно помешать работе? Логин под рутом, renice, больше он никого не волнует.
Вообще же, после 2038 года наступает сингулярность и на не-квантовых компьютерах дату позже 2038 года выставлять запрещено.
Вообще же, после 2038 года наступает сингулярность и на не-квантовых компьютерах дату позже 2038 года выставлять запрещено.
Ну до рута ещё добраться надо было. Интерфейс отзывался, но не сразу, лаги были большие.
64 битные процессоры и ОС немного откладывают эту дату.
64 битные процессоры и ОС немного откладывают эту дату.
немного?
Софт — да (кстати и некоторые 32-х битные, а некоторые даже если системный таймер ОС не умеет), процессор же — как правило, не при чем. Это я вам как (ко)разработчик многия программ (от ДБ до ситстемных и сервисных, а так же многия API) ответственно заявляю.
Например у вас а арче tcl выше 8.4 (он еще не умел), т.е. 8.5 или выше — то пример для проверки (на Win x86 кстати тоже):
Конеса наступит снова «немного» — ни мало — через полтора миллиона лет :)
Например у вас а арче tcl выше 8.4 (он еще не умел), т.е. 8.5 или выше — то пример для проверки (на Win x86 кстати тоже):
$ tclsh
% info tclversion
8.5
% clock format [clock scan {+ 100 years}]
Tue Jun 26 00:00:00 CET 2114
% clock format [clock scan {+ 1000 years}]
Sun Jun 26 00:00:00 CET 3014
% clock format 0x7fffffffffffffff
Sun Apr 24 09:29:51 CET 1583316
%Конеса наступит снова «немного» — ни мало — через полтора миллиона лет :)
Это если специально думать об этой проблеме, можно и длинную арфметику использовать. А какая-нибудь программа на C, использующая обычный int, скомпилированая в 64 битный код автоматически избавляется от переполнения на много лет (есть конечно нюансы, вдруг там дату обрабатывали битовыми операциями, строго привязываясь к размеру int).
скомпилированая в 64 битный код автоматически избавляется от переполнения на много летПро такое говорят — ваши бы слова, да богу в уши! В том смысле, что ни разу не правда и не столько в битах дело — в временах столько еще всего (вам невидимого):
структуры файловой и других систем и стандартов, структуры преобразований в API, временные зоны, корекция «високосного года» при форматировании и сканировании дат, юлианский или уже грегорианский календарь действовал и десятки и сотни других проблем сверху.
Обычный int на 64х битах, как правило, остается 32х-битным. Или вы этого не знали?
Каюсь, не знал.
А кто использует int? Все используют time_t.
Не знал, а можно подтверждение ваших слов привести?
Вот
«There are five standard signed integer types: “signed char”, “short int”, “int”, “long int”, and “long long int”. In this list, each type provides at least as much storage as those preceding it in the list.». На этом требования к вместимости этих типов заканчиваются (кроме char, ему посвящён предыдущий пункт). Инфа из открытого стандарта n3337.
И дальше если вы внимательно посмотрите, то поймёте, что если вы сделаете int 64битным, то на три размера (байт, два байта и четыре байта) у вас останутся два типа (char и short). Потому, собственно int и остаётся 32битным в 64битных системах. Вот когда long в 64битной системе оказывается 32битным (как Microsoft сделал) — вот это уже однозначно извращение.
>А какая-нибудь программа на C, использующая обычный int, скомпилированая в 64 битный код автоматически избавляется от переполнения на много лет
*кастую разработчиков одного статического анализатора кода, которые вам быстро расскажут, как вы неправы, и в очередной раз попиарят свой продукт*
*кастую разработчиков одного статического анализатора кода, которые вам быстро расскажут, как вы неправы, и в очередной раз попиарят свой продукт*
Хотя чуть подумав (должно быть больше), нашлась бага в той версии, что сейчас под рукой (нужно проверить в trunk).
Теперь скорее всего год переполняется (int32) или где-то в подсчете високосных лет слажали…
Так что зверек придет еще позднее…
Теперь скорее всего год переполняется (int32) или где-то в подсчете високосных лет слажали…
тыц (год должен убывать)
% clock format 0xfffffffffffffff
Sun Feb 05 14:56:15 CET 1269743
% clock format 0xffffffffffffff
Thu Apr 28 13:52:15 CET 2127340
% clock format 0xfffffffffffff
Sun Apr 12 04:48:15 CET 1604708Так что зверек придет еще позднее…
Вы сравниваете отрицательное число и положительные…
Да ну? Я разработчик tcl если что…
Кроме того clock оперирует в тикле «signed int64», т.е. чтобы понятней было:
Если кому интересно продолжение, это баг, во всех текущих ветках, bug-ticket здесь, но пока оценил прио low (ну кому интересны миллиарды в годах)
Поправлю на досуге.
% expr 0xfffffffffffffff
1152921504606846975
% expr 0xffffffffffffff
72057594037927935
% expr 0xfffffffffffff
4503599627370495Кроме того clock оперирует в тикле «signed int64», т.е. чтобы понятней было:
% clock format 0x7fffffffffffffff
Sun Apr 24 09:29:51 CET 1583316
% clock format 0xffffffffffffffff
integer value too large to representЕсли кому интересно продолжение, это баг, во всех текущих ветках, bug-ticket здесь, но пока оценил прио low (ну кому интересны миллиарды в годах)
Поправлю на досуге.
У вас одно ядро? Или скайп нагрузил ВСЕ ядра?
А Alt-Ctrl-F1 и прочие отключены? Или тоже не отзывались?
Разрядность процессоров не спасает. Тип time_t имеет 32 разряда, и весь стандартный софт работает именно с ним. Чтобы решить (точнее, значительно отсрочить) проблему, нужно заменить тип на 64-разрядный и переписать весь софт, что технически нетрудно (чего, однако, нельзя сказать о внедрении). Такой софт будет нормально работать и на старых процессорах тоже.
MS VS 2013:
typedef __time64_t time_t
гм…
typedef __time64_t time_t
гм…
Описанное в комментарии событие «заменить тип на 64-разрядный» у некоторых просто уже произошло:
time_t is a 32-bit value on 32-bit Windows operating systems in Visual C++ versions before Visual C++ 2005
Похоже, я был неправ. В gcc примерно так же: time_t хитрым образом определяется как long int, который, в свою очередь, зависит от архитектуры.
У нас был препод, который на полном серьезе утверждал, что Майкрософт не сможет перейти на 64-х битный процессор. И потому, всегда будет ограничено 3Гб ОЗУ.
Почему-то я его сразу вспомнил, и полез проверять :=)
Почему-то я его сразу вспомнил, и полез проверять :=)
И потому, всегда будет ограничено 3Гб ОЗУ.Видимо ваш преподователь и про сегментные регистры не слышал. И про то, что Win32 уже много лет как умеет (зависит от kernel и режима) много больше 3Гб. Другое дело что это общей памяти для всех процессов, каждый же 32-битный процесс все же ограничен 2Гб или 4Гб (LARGEADDRESSAWARE).
Ctrl-Alt-F1. login работает от рута, ему тиков должно хватить.
Сингулярность уже наступила. Просто — запас времени…
UFO just landed and posted this here
Дык а что с сертификатами то?
Всех с пятницей, всем отличных выходных! Не забудьте взять на природу шапочку из фольги.
Знающие люди говорят, что она наоборот помогает читать мысли. :)
История про 100 лет вперёд немножко проигрывает вот этой истории с переводом часов на вперёд аж на 12187 лет: habrahabr.ru/post/110174/
На самом деле автор раскрыл заговор производителей железа и софта.
В каждой программке заложен алгоритм который заставляет ее тормозить со временем. Алгоритм работает с учетом закона Мура и рассчитан на то что из за тормозов юзер поюежит в магазин за новым компом.
Что же произошло? Увидев разницу в 100 лет, скайп начал тормозить ровно на столько на сколько за эти 100 лет должны были ускорится компьютеры!
Заговор раскрыт!
В каждой программке заложен алгоритм который заставляет ее тормозить со временем. Алгоритм работает с учетом закона Мура и рассчитан на то что из за тормозов юзер поюежит в магазин за новым компом.
Что же произошло? Увидев разницу в 100 лет, скайп начал тормозить ровно на столько на сколько за эти 100 лет должны были ускорится компьютеры!
Заговор раскрыт!
Помню, что в FAT было ограничение для времени файла где-то 2037-м или 38-м. Там 7 бит использовалось, а начало было с 1900 года. Видимо тут такое же безобразие. Ну за десяток-другой лет поправят.
Sign up to leave a comment.
Дата судного дня или Microsoft наносит ответный удар