Проблема 2038 года и искусство недооценивать
Ведущие подкаста Runtime Arguments Джим Маккуиллан и Вольф посвятили выпуск целому классу ошибок, которые, по их мнению, можно было предвидеть. Отправная точка — знаменитая проблема 2038 года.
Что случится в январе 2038-го
Unix традиционно хранит время в 32-битном знаковом целом — числе секунд, прошедших с 1 января 1970 года. 19 января 2038 года счётчик переполнится: вместо перехода к следующему положительному значению он станет отрицательным и начнёт отсчёт как будто из 1901 года. Пострадает всё, что сравнивает временные метки, — например, утилита make, решающая, устарел ли объектный файл относительно исходника.
64-битные системы к проблеме невосприимчивы, ядро Linux закрыло вопрос начиная с версии 5.6 (2020), но остаётся масса 32-битных встраиваемых устройств — от светофоров до полевых датчиков давления, до которых попросту не добраться.
Почему так вышло
Маккуиллан проводит параллель с проблемой Y2K, когда год хранили двумя цифрами. Он напоминает, что за этим стояли реальные ограничения: перфокарты по 80 символов, жёсткие диски на пять мегабайт, запись только целыми секторами. Экономия каждого байта была не халатностью, а разумным компромиссом своего времени.
Вольф добавляет важную мысль: инженерные решения бывают двух родов — основанные на измерении и основанные на ощущении. «Никто не будет пользоваться этой программой через 68 лет» — это ощущение, и оно почти всегда подводит. Измерить реальность стоило бы даже тогда, когда вывод в итоге совпадает.
Парад переполнений
Далее — беглый список сбоев: проблема DJ10K (страх, что четырёхзначные поля не выдержат Dow Jones выше 10 000 в 1999-м); откаты 10-битного счётчика недель GPS в 1999 и 2019 годах; переполнение NTP, ожидаемое 7 февраля 2036 года; wraparound идентификаторов транзакций в Postgres, побеждённый автовакуумом; 51-дневный баг генераторов Boeing 787; потеря зонда NASA Deep Impact из-за переполнения счётчика десятых долей секунды; 16-битные лимиты PID и портов TCP; трудности Discord со Snowflake ID, ведь числа в JavaScript надёжно хранят лишь 53 бита; исчерпание IPv4; и жёстко зашитая дата истечения в DRM для Blu-ray, превращающая исправные плееры в электронный мусор по расписанию, которого никто не выбирал.
Отдельно — ошибки високосного года: Excel и Lotus считают 1900-й високосным, PlayStation 3 «окирпичилась» 29 февраля 2010 года, а плееры Zune замерли 31 декабря 2008-го.
Вывод
В финале Вольф сводит всё к ценностям: писать нужно код, который сможет починить и поддержать любой, а не рычаг, за который умеешь дёргать только ты сам. Такая «защита рабочего места через непрозрачность» оборачивается тем, что дёргать рычаг придётся снова и снова.
Источник: Lobsters
Комментарии
Войдите, чтобы комментировать.