Как стать автором
Обновить

Вышла GNU Autoconf 2.72 с поддержкой стандарта C23 и опцией безопасности --enable-year2038

Время на прочтение1 мин
Количество просмотров1.6K

22 декабря 2023 года вышла стабильная версия GNU Autoconf 2.72. В новой версии утилиты для создания конфигурационных скриптов добавлена поддержка стандарта C23 (языка программирования C) и стала доступна опция безопасности --enable-year2038, которая выявляет наличие в системе 32-битного (signed integer) таймера time_t.

Читать далее
Всего голосов 7: ↑7 и ↓0+7
Комментарии1

Баг Y292B: мы обречены (снова)

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров7.2K

Измерение времени — очень сложная задача. Я выяснил это, набив шишки при попытке запрограммировать расширяемый хронометр для небесных тел Солнечной системы. Сложность в том, что все календарные системы имеют так много правил и исключений, что сборщик календаря, по сути, становится ещё одним языком программирования. Впрочем, мне хорошо знаком закон Завински*, поэтому я постарался избежать создания ещё одного Emacs.

*Закон Завински — выдуманный закон computer science, высмеивающий неизбежное разрастание фич. Он гласит, что каждая программа рано или поздно постарается прочитать электронную почту. Стоит отметить, что закон сформулирован в 90-х, поэтому и речь об электронной почте. Кстати, я нашёл хороший веб-сайт с другими законами computer science.

Основные проблемы хронометража заключаются в неодинаковых интервалах корректировки, постоянно меняющихся часовых поясах и преобразованиях из одной системы хронометража в другую. Кроме этих алгоритмических проблем существуют ограничения устройств, например, точность генератора или ёмкость памяти. В наше время на них обычно не обращают внимание, в частности, примерно со времени решения проблемы бага Y2K распределение памяти вообще не считается серьёзной проблемой.

Y2KY2038 и другие баги Y2xx — это на самом деле не совсем «баги», а простые переполнения выделенного пространства памяти. Unix и подобные ему компьютерные системы измеряют время, выполняя инкремент секунд в единой целочисленной переменной time_t. Естественно, такой хронометраж назван временем Unix, а 0 в нём означает полночь 1 января 1970 года.

В разных реализациях времени Unix для time_t используются разные типы данных. Когда тип данных достигает своего верхнего предела, он «сбрасывается» или до обратного (отрицательного) значения, или до нуля. В текущей основной ветви ядра Linux используются 64-битные числа со знаком. В таком решении точка сброса приходится на 292 277 026 596 год. Он настанет примерно через 292 миллиарда 277 миллионов 24 тысяч лет.

Но что потом?

Читать далее
Всего голосов 6: ↑5 и ↓1+9
Комментарии10

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

Время на прочтение3 мин
Количество просмотров89K
За последние пару лет я потратил много времени на дебаггинг чужих тестов. Это была интересная работа, иногда расстраивающая, но всегда поучительная. Кто-то может подумать, что в тестах нет багов, но конечно баги есть везде, и тесты не исключение.

Я постоянно удивлялся, как много ошибок в коде и тестов, и приложений происходят от неверного понимания и заблуждений насчёт времени. Под этим я имею в виду и компьютерный способ обработки времени, и фундаментальные ошибки, происходящие от несовершенной структуры календаря — летнее время тут лишь вершина айсберга.

На самом деле, я повидал так много заблуждений, которые оставляют след в чужих (и моих собственных) программах, что посчитал полезным составить список самых частых проблем.
Читать дальше →
Всего голосов 241: ↑218 и ↓23+195
Комментарии216

1 января 1904, 1970, Youtube, международный конфликт и кривые руки

Время на прочтение2 мин
Количество просмотров79K
К сожалению, давно пропали топики-ссылки, но иногда бывают крайне занимательные вещи из первых рук. Рекомендую пост Анатолия Воробея (работает разработчиком в «Гугле»).

В видеоформате MP4 (стандарт MPEG-4) есть возможность записать «время создания» любого потока данных, с помощью специальной метки. Значение этой метки в стандарте: количество секунд, прошедших с 1 января 1904 года, или так называемое «время по эпохе макинтоша», потому что маки первыми стали использовать такой отсчет времени. Меж тем, в современных серверах намного проще иметь дело с «временем по эпохе Юникса», а именно количеством секунд, прошедших с 1 января 1970 года. В результате этого, во множестве программ, которые работают на Линуксе или других юниксовских операционных системах, есть кусок кода, который выглядит примерно так:
  • получить «время сейчас по юниксу»;
  • добавить разницу между временем по юниксу и временем по макинтошу — это некая константа;
  • полученное «время сейчас по макинтошу» записать в файл MP4, который мы создаем.

Чему равна константа «разница между временем по юниксу и временем по макинтошу»? Она равна в точности числу секунд, прошедших между 1 января 1904 и 1 января 1970. Это 66 лет, из которых 17 были високосными (проверьте, если не доверяете мне). Всего дней получается: 66 * 365 + 17 = 24 107, а секунд, учитывая 86 400 секунд в сутках: 24 107 * 86 400 = 2 082 844 800. Это правильное значение константы.
А как же обстоят дела в Ютьюбе
Всего голосов 270: ↑246 и ↓24+222
Комментарии25

Время — иллюзия, время Unix — иллюзия вдвойне…

Время на прочтение13 мин
Количество просмотров31K

Как вы хорошо знаете, в Unix-системах мы измеряем время как количество секунд, прошедших с «эпохи»: 00:00:00 UTC 1 января 1970 года. Немало людей сильно разозлилось из-за этого, да и вообще, общественное мнение сочло это ошибкой.

Во-первых, это определение основано не на чём-то разумном, например, на объективной частоте колебаний атома цезия-133, а на удобной доле времени полного оборота одного большого камня вокруг собственной оси.

Во времени Unix каждый день гарантированно состоит из 86400 секунд и мы притворяемся, что это число равномерно увеличивается. Когда оказывается, что вышеупомянутый камень на самом деле вращался дольше, чем удобно для нас, и нам нужно добавить секунду координации, то мы просто притворяемся, что этого не было, а механизм меток времени не идентифицирует уникальный момент времени.

Ещё один аспект, который продолжает вызывать проблемы, когда мы пытаемся считать секунды, заключается в том, что мы сталкиваемся с проблемами хранения и описания данных, потому что, как оказалось, компьютеры не так уж хорошо справляются с числами. Не говоря уж об "эпохальном сбое".
Читать дальше →
Всего голосов 47: ↑46 и ↓1+60
Комментарии77

15000 день unix эпохи

Время на прочтение1 мин
Количество просмотров2.8K
Сегодня, 26 января, в полночь по GMT, наступил 15000 день от начала летоисчисления Unix машин. Юниксоиды всех стран встречаются, празднуют, проводят массовые гуляния и гадают. Встречи локальных групп можно найти на специальном сайте, посвящённом этому знаменательному дню.
День можно посмотреть командой:
$ echo `date +%s`/86400|bc
Всего голосов 133: ↑118 и ↓15+103
Комментарии42

Путешествие к центру… docker image. Или как скачать образ из registry без docker

Время на прочтение9 мин
Количество просмотров12K

За 3 дня до нового года появилась задача, передать клиенту наше ПО через менеджера, на флешке. ПО – это микросервисная платформа в несколько десятков docker-образов с множеством настроек и “километровым” helm-чартом. Что мы имели:


  • Менеджер в Москве (я не оттуда)
  • Windows
  • Прямого взаимодействия нет (а если бы и было, то не особо помогло)
  • docker-а нет

Пфф, подумал я! Возьму Golang, напишу программку, скомпилирую под Windows.
… и 5 часов спустя осознал поспешность своих выводов. В тот момент в первый раз вспомнился смех Нельсона. ХА-ХА! Который преследовал меня все то время, что я потратил на изучение вопроса.

Читать дальше →
Всего голосов 13: ↑12 и ↓1+21
Комментарии13

Поломанные VPN, 2038 год и сертификаты с истёкшим сто лет назад сроком

Время на прочтение7 мин
Количество просмотров18K

В конце 2010 года Зимми (псевдоним) работал в ИТ-поддержке компании, разрабатывавшей VPN-устройства и операционную систему для них. В понедельник ему позвонил клиент (розничный продавец продукции из США), рассказавший, что в выходные его VPN-оборудование перестало работать.

После изучения отчёта Зимми решил, что проблема возникла в результате сбоя валидации сертификата, о чём он и написал в недавнем посте в Mastodon.

«VPN-устройства моего работодателя управлялись через центральный сервер. На этом сервере работал собственный центр сертификации (CA), который использовался для подписывания сертификатов всех устройств. Конечные точки VPN использовали их для аутентификации на сервере управления (например, при отправке логов) и друг между другом (в основном для VPN). CA — это фундаментальная часть ПО управления».

Зимми сообщил, что предпочёл бы оставить анонимным себя, компанию и клиента.

Валидация оказывалась ошибочной, потому что система не могла проверить certificate revocation list (CRL) — список цифровых сертификатов, отозванных выпустившим их центром.

«Эти устройства аутентифицировали друг друга при помощи сертификатов, похожих на те, которые применяются для HTTPS, но подписанные частным центром сертификации. У каждого клиента был для этого свой CA. В процессе валидации сертификатов CA проверял, не отозван ли сертификат. Валидацию не удавалось выполнить, потому что VPN-устройство не могло скачать certificate revocation list (CRL), чтобы убедиться, что сертификата другого устройства нет в списке. Почему оно не могло скачать CRL?»
Читать дальше →
Всего голосов 42: ↑41 и ↓1+59
Комментарии10