Представьте файл на восемь мегабайт. Внутри — одна очень длинная строка: aa=1&bb=2&cc=3&… и так несколько сотен тысяч раз. Ничего особенного — обычное тело POST-запроса, какие веб-сервер разбирает тысячами в секунду. Кроме одной детали: имена параметров подобраны с точностью криптоаналитика так, чтобы все до единого давали одинаковый хеш.

Отправьте этот файл на сервер PHP образца 2011 года — и получите сервер, занятый примерно на час. Один запрос. Один процессор. Сто процентов загрузки. Замените PHP на Java, Python, Ruby, ASP.NET или Node.js — ничего не изменится: та же сотка, тот же час. Мегабитный канал превращается в инструмент, способный положить целый кластер, — без ботнета, без уязвимости в приложении, без флуда. Просто очень тщательно сделанная форма.

Ровно это и демонстрировали Александр Клинк и Юлиан Велде 28 декабря 2011 года на конференции 28C3 — в докладе с невинным названием «Эффективный отказ в обслуживании веб-платформ». К следующему утру появились первые записи CVE: CVE-2011-4885 — PHP, CVE-2011-4858 — Tomcat, и дальше — целая серия для остальных. Неделю новостных лент спустя отрасль уже переписывала реализации хеш-таблиц.

Хуже всего было то, что атаку предсказали восемь лет назад — и все пропустили предсказание.

Предсказание, которое никто не услышал

В 2003 году двое исследователей из Университета Райса, Скотт Кросби и Дэн Уоллач, опубликовали статью с сухим академическим названием — «Denial of Service via Algorithmic Complexity Attacks». В переводе: «Отказ в обслуживании через атаки на вычислительную сложность».

Кросби и Уоллач описали сценарий с хирургической точностью: если протокол принимает пользовательские данные в хеш-таблицу, а хеш-функция предсказуема, атакующий может заранее вычислить ключи-коллизии. Таблица, которая должна работать за миллисекунды, деградирует до связного списка. В статье авторы показали, как с помощью этой техники можно положить Perl, Python-веб-приложения и сетевое устройство Snort.

Статья получила вежливые отзывы, несколько ссылок в академических кругах и легла на полку. Разработчики Perl пофиксили свою хеш-функцию — единственные из всей индустрии. Остальные сочли атаку «теоретической».

Понадобилось восемь лет и одна публичная демонстрация на 28C3, чтобы все языки программирования массово начали переписывать реализации своих хеш-таблиц.

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

От картотеки к массиву: как всё начиналось

Январь 1953 года. Ханс Петер Лун, инженер IBM, трудится над задачей, которая сегодня кажется смешной: нужно быстро найти карточку в картотеке из тысяч записей. Компьютеры тогда занимали комнаты, а «память» измерялась не в гигабайтах, а в магнитных барабанах.

Лун рассуждает как инженер. Если у нас есть полка на сто ячеек, и мы кладём каждую карточку наугад, поиск в среднем потребует просмотра половины полки. Но что если от самой карточки вычислить число, а потом положить её в ячейку с этим номером? Тогда и искать можно в одно действие: вычислить число от запроса и сразу прыгнуть к ячейке.

Это и был прообраз хеш-таблицы. Внутренний документ IBM, в котором Лун её описал, никогда не публиковался в открытом доступе. Мир узнал о приёме позже, из работы Арнольда Думи, Джина Амдала и других. Но первым был именно Лун.

Смысл приёма простой до неприличия:

1. Есть массив, скажем, на 16 ячеек.
2. От ключа («Иванов», 42, адрес страницы) вычисляем хеш — число, которое должно равномерно размазывать разные ключи по всему диапазону.
3. Берём остаток от деления хеша на 16, получаем индекс ячейки.
4. Кладём туда значение.

Поиск работает так же: вычислил хеш, взял остаток, прыгнул в ячейку. Одно действие. То самое O(1), за которое хеш-таблицу любят все.

Когда два ключа хотят в одну ячейку

А теперь представьте: у нас 16 ячеек, а ключей мы вставляем двадцать. По принципу Дирихле хотя бы двум ключам обязательно достанется один и тот же индекс. Это называется коллизией, и с ней надо что-то делать.

Есть два принципиально разных подхода.

Цепочки. В каждой ячейке живёт не значение, а связный список. Столкнулись двое — добавили к списку. Просто, надёжно, но список разбросан по памяти мелкими кусочками. Процессор ненавидит такую раскладку: каждый переход по указателю — потенциальный промах кеша, то есть сотня тактов ожидания оперативной памяти.

Открытая адресация. Ячейка занята — идём к следующей. Этот подход похож на парковку у торгового центра: если твоё место занято, ищешь ближайшее свободное. Данные лежат подряд, процессор доволен. Но удаление превращается в головоломку: если просто очистить ячейку, поиск сломается. Он остановится на «дырке», не дойдя до нужного ключа. Приходится помечать ячейки как «удалённые, но не пустые».

Оба подхода работают идеально в среднем. Проблема начинается, когда кто-то специально подбирает ключи, которые сталкиваются.

Когда O(1) превращается в O(n)

Вернёмся к докладу на 28C3. Вся красота атаки именно в этом превращении.

Пусть атакующий знает: веб-сервер парсит параметры запроса foo=1&bar=2&baz=3 в хеш-таблицу, а хеш-функция — детерминированная и известная (в 2011 году всё это было открыто задокументировано). Тогда он заранее, на своём ноутбуке, подбирает тысячу имён параметров, которые все хешируются в одно и то же число.

Сервер получает безобидный на вид POST-запрос. Начинает вставлять параметры. Первый — O(1). Второй — O(1), но таблица уже знает: в этой ячейке коллизия, надо сравнивать. Третий — уже сравнивается с двумя. К тысячному параметру каждая вставка — это обход тысячи коллизий. Суммарно — O(n²), где n — количество параметров.

На демонстрации Клинк и Велде показали: POST-запрос в 8 МБ занимал сервер на PHP примерно на час. Один запрос. Один мегабитный канал — и можно положить целый кластер. Ни флуда, ни ботнета, ни уязвимости в приложении. Просто очень тщательно составленный запрос.

Ответ: SipHash и секретный ключ

Инженерное сообщество отреагировало быстро и в три голоса.

Во-первых — лимиты. PHP добавил директиву max_input_vars. Tomcat, Jetty и другие серверы приложений ввели аналогичные ограничения. Это костыль, но рабочий: атакующий не может отправить миллион параметров, если сервер принимает максимум тысячу.

Во-вторых — рандомизация. Если хеш-функция зависит от секретного числа, которое выбирается при запуске программы, предсказать коллизии заранее невозможно. Атакующий больше не может на своём ноутбуке подобрать «ядовитые» ключи. Для этого ему нужно как-то добыть сам секрет из работающего сервера.

В-третьих — криптография. В 2012 году Жан-Филипп Омассон и Даниэль Бернштейн опубликовали SipHash — хеш-функцию, специально спроектированную для защиты хеш-таблиц. Это не классическая криптографическая функция вроде SHA-256. Для хеширования паролей она не годится. Но у неё есть ключевое свойство: без знания секретного ключа подобрать коллизии математически невозможно (точнее, эквивалентно взлому стойкого шифра).

SipHash стал стандартом де-факто. Python перешёл на него в версии 3.4. Ruby, Perl, Rust, Haskell — все последовали примеру. Это редкий случай, когда академическая статья за несколько лет стала промышленным стандартом.

Робин Гуд против богачей

Пока одни исследователи разбирались с безопасностью, другие воевали за скорость.

В 1986 году канадский аспирант Педро Селис защитил диссертацию с задорным названием Robin Hood Hashing — «Хеширование Робин Гуда». Идея простая и очень красивая.

Когда мы вставляем ключ при открытой адресации и натыкаемся на занятую ячейку, мы идём дальше. Каждый такой шаг — это «бедность»: чем дальше элемент от своей идеальной позиции, тем больше он страдает при каждом поиске. Обычная открытая адресация несправедлива: «богачи» (те, кто попал на своё место с первого раза) живут спокойно, а «бедняки» обречены на длинные поиски.

Селис предложил: при вставке сравнивать, кто больше «настрадался». Если новый ключ уже прошёл дальше, чем ключ в текущей ячейке, они меняются местами. Новый ключ занимает ячейку, а «богач» идёт искать место дальше. Забираем у тех, кому повезло, отдаём тем, кому нет, отсюда и название.

Результат выглядит скромно, но на деле впечатляет. В обычной открытой адресации при заполнении 90 % дисперсия длины поиска — 16,2 шага. В варианте Робин Гуда — 0,98 шага. То есть поиски становятся не просто быстрыми в среднем, а одинаково быстрыми. Хуже почти никому не будет.

Rust с самого начала и до 2019 года использовал именно Робин Гуда. Это был хороший выбор до тех пор, пока не появился следующий.

Swiss Tables: как 16 сравнений стали одним

В 2017 году на конференции CppCon инженер Google Мэтт Кулукундис вышел на сцену с докладом «Designing a Fast, Efficient, Cache-friendly Hash Table, Step by Step». За 45 минут он рассказал, как команда Google — сам Кулукундис, Сэм Бензакен, Алкис Эвлогименос и Роман Перепелица — переписала хеш-таблицу для внутренних сервисов компании. Результат назвали Swiss Table (по аналогии со швейцарским сыром: много аккуратных «дырок» — свободных ячеек).

Ключ к скорости — инструкции SIMD (Single Instruction, Multiple Data, «одна инструкция на много данных»). Идея такая:

1. Хеш ключа делится на две части: длинную (57 бит) и короткую (7 бит). Длинная часть определяет, в какой группе из 16 ячеек искать. Короткая — «отпечаток», который хранится отдельно, в массиве метаданных по одному байту на ячейку.
2. При поиске процессор одной инструкцией загружает 16 байт метаданных в 128-битный регистр. Ещё одной инструкцией (_mm_cmpeq_epi8) сравнивает отпечаток искомого ключа сразу со всеми 16 ячейками. Результат сравнения — битовая маска: где совпало, там и смотрим реальный ключ.

По сути, шестнадцать шагов поиска за одну машинную команду. На реальных нагрузках Google прирост оказался двукратным, и это при том, что прежняя реализация уже была очень хорошей.

История на этом не кончается. Когда Swiss Table открыли как часть библиотеки Abseil в 2018 году, другие языки потянулись следом. Rust в 2019-м заменил Робин Гуда на библиотеку hashbrown — порт Swiss Table. Go в версии 1.24 (февраль 2025) выбросил свою схему с цепочками по 8 элементов и переехал на Swiss Table — карты стали до 60 % быстрее на типичных операциях.

Go и сознательный хаос: история рандомизации

Из всей этой саги особняком стоит решение, принятое командой Go ещё в 2012 году, и это одна из лучших историй о том, как проектировать язык.

До Go 1.0 порядок обхода map через range был детерминированным. Ну, или почти — он зависел от деталей реализации. Программисты быстро это обнаружили и начали писать код, зависящий от порядка: тесты, которые сравнивали сериализованные строки, кеши, где порядок влиял на результат, логи, где хотелось «одинакового вывода».

Команда Go поняла: если оставить как есть, любое будущее изменение внутренней реализации сломает чужой код. И приняла смелое решение — специально внести случайность. При каждом вызове range стартовая ячейка выбирается случайно через быстрый генератор fastrand(). Два цикла range подряд по одной и той же карте дадут разный порядок.

Это не защита от атак. Это защита от себя — от программистов, которые случайно (или специально) начнут зависеть от порядка и превратят деталь реализации в часть контракта. Когда в Go 1.24 заменили всю реализацию хеш-таблицы целиком, ни одна программа не сломалась, потому что зависеть было не от чего.

Мораль простая: если деталь реализации не должна быть частью контракта, надёжнее всего сделать её явно случайной. Иначе её неизбежно начнут использовать, и однажды это создаст проблемы.

Теперь, когда история понятна, посмотрим на то, что лежит в «коробке» у современных языков.

Хеш-таблицы в четырёх языках

Rust. Стандартный HashMap — это библиотека hashbrown, порт Swiss Table, с хеш-функцией SipHash-1-3. Каждый запуск программы выбирает новый секретный ключ. Попытка отсортировать содержимое карты по ключам требует явного сбора в Vec — HashMap принципиально не реализует упорядоченность.

Go. После 1.24 — Swiss Table. Хеш-функция из пакета hash/maphash получает собственный секретный ключ при каждом создании карты. Сравнить две карты через == компилятор не даст.

Zig. Есть StringHashMap для строковых ключей и AutoHashMap для типов, у которых хеш можно вывести автоматически. Аллокатор передаётся явно. Можно использовать арену для временных таблиц, что в «больших» языках недоступно. По умолчанию используется Wyhash — быстрая, но некриптографическая функция. Встроенной рандомизации секретного ключа нет. Это решение пользователь принимает сам.

Nim. В стандартной библиотеке имеется модуль std/tables с типами Table[K, V] (неупорядоченная) и OrderedTable[K, V] (сохраняет порядок вставки; в Go и Rust отдельного типа нет — его пришлось бы собирать руками). Хеш-функция берётся из std/hashes, стандартная реализация для строк детерминирована между запусками. Рандомизация секретного ключа — задача разработчика: либо подмешивать собственный seed, либо подключать сторонний SipHash.

Примеры кода:

• hash_demo.rs — Rust;
• hash_demo.go — Go;
• hash_demo.zig — Zig;
• hash_demo.nim — Nim.

История повторяется: свежие уязвимости

Мы говорим о 2011 годе как о далёком прошлом, но класс уязвимостей никуда не делся. Стоит разработчику забыть о рандомизации, как проблема возвращается:

• CVE-2024-21538 в пакете cross-spawn — предсказуемый разбор путей приводит к квадратичному времени;
• CVE-2024-4067 в micromatch — коллизии в разборе шаблонов для поиска файлов;
• CVE-2024-21490 в Angular — регулярные выражения плюс хеш-таблица.

Общее правило простое. Любая система, которая принимает пользовательский ввод и кладёт его в структуру данных, чувствительную к распределению ключей, потенциально уязвима. Если хеш-функция не рандомизирована — уязвима гарантированно.

Что осталось за кадром

Хеш-таблица — одна из тех структур, без которых современное программирование невозможно представить. dict в Python, объект в JavaScript, map в Go, HashMap в Rust, Table в Nim — под всеми этими разными именами работает одна и та же идея Ханса Петера Луна, которой скоро исполнится 75 лет.

Но за уютным фасадом O(1) скрывается долгая инженерная драма: выбор функции, борьба с коллизиями, защита от атак, компромисс между скоростью и предсказуемостью. Swiss Table с SIMD-пробированием — вершина эволюции на сегодня. Если история чему-то учит, через пять-десять лет появится следующая, и мы снова будем переписывать стандартные библиотеки.

А самое важное — помнить, что O(1) существует только на бумаге. В реальности всегда есть ключи, которые сделают ваш сервер очень, очень медленным. Вопрос только в том, догадается ли об этом атакующий раньше вас.

Источники

• Denial of Service via Algorithmic Complexity Attacks (Crosby, Wallach, 2003) — предсказание HashDoS за восемь лет до атаки;
• Effective DoS on Web Application Platforms (Klink, Wälde, 28C3, 2011) — доклад, перевернувший веб-разработку;
• SipHash: a fast short-input PRF (Aumasson, Bernstein, 2012) — спецификация функции, защитившей отрасль;
• Swiss Tables Design Notes (Abseil) — описание Swiss Table от Google;
• Faster Go maps with Swiss Tables (Go Blog, 2025) — переход Go на Swiss Table;
• hashbrown — Rust HashMap implementation — реализация Swiss Table для Rust;
• Robin Hood Hashing (Sebastian Sylvan) — объяснение алгоритма Селиса;
• Go Map Iteration Order Randomization (Issue #6719) — история рандомизации порядка обхода в Go.

Ирвин никак не мог понять, что ему не нравится в строчках выполненного домашнего задания по программированию. Среда разработки iBasic радостно подмигивала зелёным: ошибок в коде не было. Но мальчику всё равно казалось, что чего-то здесь не хватает. Изящества, выразительности, лаконичности, — чего-то неуловимого, чего-то, что он, ученик восьмого класса лицея имени Стива Джобса не мог сформулировать. Ирвин привычным жестом закрыл среду iBasic, щёлкнул по увесистому кубику учебника истории и приступил к изучению параграфа, заданного на дом. Перед глазами появилась реконструкция Ледового побоища из исторического фильма. Крики, стоны и звон оружия заполнили крошечную комнату. Социальное жильё никогда не бывает просторным.

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

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

— Мартин Купер, вы нарушили имущественные права корпорации АйГейпл, повторно просмотрев фильм «Ледовое побоище», — прогремел усиленный мощной аудиосистемой голос. — Для совершения преступления вы использовали запрещённые законом хакерские инструментальные средства, что существенно отягощает вашу вину. За это в соответствии с законом вы приговариваетесь к тюремному заключению сроком на пятнадцать лет. Ваше имущество будет конфисковано для компенсации нанесённого ущерба. Ваш сын Ирвин Купер переходит под опеку корпорации, ему выделят социальное жильё в квартале имени Марка Збиковски. Приговор окончательный, аппеляция не предусмотрена. У вас есть пять минут, чтобы попрощаться с сыном.

От грохота голоса Ирвин задрожал. Смысл слов судьи с трудом доходил до сознания. Отец обнял его, и погладил по голове. А потом отстранился и глядя прямо в глаза, произнёс: «Ирвин, ничего не бойся! Учись как следует и живи дальше. Со мной всё будет в порядке. И не верь ничему, что будут говорить и писать обо мне!» Потом он вытер слёзы, катившиеся из глаз Ирвина, обнял его ещё раз и повернулся к неподвижной фигуре судьи: «Я готов!»

Судья махнул рукой, раздался щелчок смарт-замка, и дверь в квартиру Куперов открылась. На пороге стояли трое мужчин в форме с нашивками в виде надкушенного яблока с двумя перекрещенными поверх него мечами.

— Копирайт-полиция АйГейпл. Мартин Купер, следуйте за нами! — скомандовал черноволосый здоровяк.

Отец спокойно пошёл к выходу. У Ирвина внутри всё опустилось.

— Папа! — рванулся он следом, но копирайт-полицейский его остановил.

— Не торопись. Тебе не по пути с твоим отцом. Для тебя жизнь приготовила другое кино.

Ирвин пытался вырваться, но силы были неравны. Трепыхаясь в крепких руках стража порядка, он успел заметить странный жест, который сделал отец, выходя из квартиры — собрал пальцы в щепоть, нарисовал ими в воздухе тройной круг и ткнул в его середину.

— Заходи, Ирвин, это твой новый дом. Не хоромы, конечно, но жить вполне можно. Тебе повезло, ты будешь жить здесь один, а некоторые твои соседи делят такую комнату на троих, а то и на четверых.

Ирвин слушал мягкий голос социального работника и пытался рассмотреть комнату, в которую его привели. Крохотное окно-иллюминатор под потолком, тусклое светодиодное освещение, серые стены, пластиковый пол, откидной стол, откидная кровать, умывальник. Он повернулся к своему сопровождающему.

— Мистер Кук, а где здесь…

— Туалет и душ в коридоре общего пользования. Для этой категории жилья индивидуальные санузлы не предусмотрены.

Ирвин тяжело вздохнул. Сказать, что комната была тесной — это не сказать ничего. Ему казалось, что стены сближаются и пытаются его раздавить. Он сглотнул появившийся в горле комок.

— Ничего, ты привыкнешь. Все привыкают. Еду будешь получать в автомате рядом с лифтом. Нажимаешь кнопку, автомат считывает твой идентификатор со скинекта и выдаёт порцию горячей еды. Не вздумай хитрить, добавки здесь никому не полагается. Завтрак можно получить с шести до семи утра, ужин — с шести до восьми вечера. Не возьмёшь еду в это время — останешься голодным. Обедать будешь в школе. Разносолов не жди, всё очень просто и питательно. Деньги на проезд в школу и обратно будут ежемесячно зачисляться на твой личный счёт. Потратить их на что-то другое ты не сможешь. Если у тебя возникнут какие-то вопросы — мои контактные данные в твоём скинекте. Осваивайся, знакомься с соседями. Они тебе расскажут, что здесь и как. Удачи! И постарайся не повторять ошибок своего отца!

Мистер Кук повернулся и ушёл. Ирвин остался один. Дверь со щелчком закрылась, и этот звук показался ему оглушительным. Только сейчас он окончательно осознал бесповоротность произошедшего. Чтобы не разреветься, мальчик принялся осматривать новое жилище.

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

Ирвин снял рюкзак с личными вещами, достал планоут, включил. «Подключено к сети MZ» — бодро отрапортовал планоут. «Вам сообщение от социальной службы. Прочитать сейчас?» Ирвин сделал подтверждающий жест — поднял большой палец. В воздухе над планоутом появился прямоугольник информационного видеописьма.

Сначала появилась заставка с эмблемой социальной службы АйГейпл. Затем пространство голопроекции заполнила фигура полноватого мужчины в очках. Он посмотрел прямо на Ирвина, кашлянул и заговорил.

— От имени социальной службы корпорации АйГейпл приветствую вас в квартале имени Марка Збиковски. Это жильё сделано по специальному проекту корпорации под названием «Технологии против нищеты». С гордостью могу констатировать, что проект оказался весьма успешным, и на территориях, управляемых корпорацией, нищета как явление полностью отсутствует.

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

Скинект — уникальный идентификатор гражданина, заменивший все прочие виды удостоверений личности. Это кошелёк, медицинский ассистент и персональный цифровой помощник. С помощью скинекта граждане получают доступ к сети Айнет, созданной усилиями нашей замечательной корпорации. В отличие от устаревшего Интернета Айнет совершенно безопасна, в ней нет места вирусам, воровству и пиратству. Корпорация АйГейпл разработала технологии, которые защищают граждан от всех угроз, связанных с работой в сети. Если вы получили сообщение, то можете не сомневаться, что его прислал вам именно тот человек, который значится в поле «Отправитель». Благодаря обязательной идентификации нам даже удалось победить спамеров, от которых во времена Интернета не было спасения.

С помощью скинекта вы можете транслировать изображение и звук на любое устройство, например, на планоут или на голопроектор. Управлять работой скинекта можно с помощью пульта медиаустройства, с клавиатуры планоута или его сенсорного экрана, с помощью жестов, которые замечательно распознаются встроенными в скинект датчиками положения в пространстве, или с помощью голоса. Благодаря скинекту вы никогда не заблудитесь, ведь в нём есть чипы для всех систем спутниковой навигации. Для работы скинект использует тепло вашего тела, поэтому вам никогда не придётся думать о замене батареек.

Реализуя стратегию «Own different» («Владей иначе»), корпорация АйГейпл предоставила всем без исключения доступ к богатству цифрового контента. Каждый может смотреть фильмы, слушать музыку и читать книги. Для этого мы предоставляем базовый информационный пакет абсолютно бесплатно. В него включены лучшие произведения, созданные человечеством за много лет, а также свободный доступ ко всем публичным ресурсам Айнет.

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

Мы в корпорации АйГейпл уважаем право авторов на получение вознаграждения за труд, поэтому исправно платим все авторские отчисления и обеспечиваем доступ к самым новым произведениям для всех желающих в рамках платного информационного пакета «Новинки»…

Ирвин зевнул. Большую часть из того, о чём рассказывал мужчина в очках, он знал раньше. Только перемотать видеопослание было нельзя, он уже пытался сделать перематывающий жест рукой, но получил сообщение о том, что содержимое защищено от перемотки.

С пакетом «Новинка» он познакомился в лицее. У всех его одноклассников этот пакет был подключен, в то время как у Ирвина, разумеется, его не было. Это было ещё одним поводом для насмешек, которые мальчик в изобилии получал в свой адрес.

Учиться в лицее Ирвину очень нравилось, если бы не насмешки одноклассников. После ареста отца мальчик стал главной мишенью для разных жестоких шуток. Поводом для издевательств становилось абсолютно всё — от его одежды и устаревшей прошивки на скинекте до отсутствия подписки на «Новинки». Каждый день начинался примерно одинаково.

— Эй, Купер, как тебе вчерашняя серия «Хакеров АйНета»? — с деланным интересом обращался к нему Ник Кимбол — упитанный розовощёкий блондин, сын мелкого начальника одного из подразделений АйГейпл.

— Мне кажется, ему не понравилось, — подхватывал его дружок по фамилии Гилмор. — В квартале имени Збиковски вам не найти камней Сваровски. Как и подписки на «Новинки», правда, Купер? У вас там хоть электричество есть? Или его, как воду в душе по расписанию включают?

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

Одноклассники не только портили Ирвину настроение, но и создавали реальные сложности. Например, он не мог начать делать домашнее задание, пока ехал из лицея домой на скоростном экспрессе из-за того, что планоут постоянно показывал заставку с непристойной надписью. Его мучители каждый день устанавливали эти надписи с помощью функции, появившейся в новой платной прошивке скинекта, которой у Ирвина, разумеется не было: его скинект устанавливал только исправления ошибок. Картинка пропадала лишь когда мальчик попадал в зону действия сети квартала Марка Збиковски: дистанционная трансляция изображений здесь не поддерживалась.

Однажды, вернувшись из лицея, Ирвин в очередной раз вспомнил о странном жесте, который сделал отец во время ареста и попытался повторить его: собрал пальцы в щепоть, трижды нарисовал ими круг и ткнул в центр. И вдруг… Крошечная комната социального жилья погрузилась в темноту. Среди полной темноты — окон в социальном жилье не предусмотрено — тускло засветился голоэкран планоута. Над экраном появилось … лицо отца. Отец улыбнулся и подмигнул Ирвину.

— Привет, сынок! Я рад, что ты, наконец, догадался.

— Папа… — Ирвин был настолько потрясён, что потерял дар речи.

— Да, это я. А ты, я смотрю, стал таким взрослым. По моим подсчётам ты учишься уже в восьмом классе. Я не ошибся?

— В восьмом… — эхом повторил Ирвин.

— И как твои успехи в учёбе? Алгебра, геометрия, теория вероятности, основы криптографии, информатика, алгоритмы и структуры данных

— Дда, всё кроме криптографии и алгоритмов. На информатике мы изучаем iBasic.

— Только iBasic и всё?? — возмутился отец. — Да они что, совсем с ума посходили

— Ещё нас учат рисовать в айПаинте, — попытался оправдаться Ирвин. — Я разговаривал с соседскими ребятами, которые учатся в обычной школе. У них нет ничего подобного. Их учат только работать в Айнете, делать покупки в магазине АйГейпл и оформлять подписку на «Новинки».

Мальчика не покидало чувство нереальности происходящего. Отец, конечно, хорош — вместо того, чтобы спросить, как он живёт, выясняет подробности его обучения.

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

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

— Но-но, поосторожнее говори про скинект, он может и обидеться, — улыбнулся отец. — Я, помнится, встроил в него довольно продвинутый искусственный интеллект, и всё, что тебе нужно — это правильно к нему обратиться.

— Искусственный интеллект? Разве это уже возможно?

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

— Пап, а почему я всё ещё учусь в лицее имени Джобса? Почему меня не перевели в обычную школу, ведь из нашей квартиры меня выселили?

— Сынок, я в своё время оказал очень большую услугу корпорации АйГейпл — написал для них базовую систему управления скинектом. Это операционная система в миниатюре, без которой скинект не может работать. TuneOS — операционная система скинекта, с которой имеют дело пользователи, работает уже поверх этой мини-ОС. За это мне полагалось очень хорошее вознаграждение в виде отчислений за каждый подключенный скинект. Я решил, что мне ни к чему столько денег сразу, поэтому договорился, что компания заключит договор с лицеем Стива Джобса, и пока ты там учишься, всё вознаграждение будет перечисляться на счёт лицея. По моим расчётам этих денег было бы достаточно для обучения пятерых учеников, но к чему мелочиться? Поскольку договор заключался не от моего имени, ты до сих пор продолжаешь учиться в лицее. Сумма оказалась настолько внушительной, что лицей проигнорировал мой арест. Когда закончишь учёбу, деньги будут поступать на твой личный счёт. Подожди благодарить! Слушай внимательно, что тебе нужно сделать…

Отец рассказал Ирвину, что на его скинекте установлена специальная операционная система — LuxOS, которая для непосвященного выглядит как самая обычная TuneOS. Отличие в том, что эта система позволяет делать значительно больше, чем TuneOS. LuxOS не передаёт информацию о действиях пользователя в АйГейпл, в ней можно свободно читать книги, слушать любую музыку, смотреть любые фильмы и писать программы не только на iBasic.

Это понравилось Ирвину больше всего. Свобода — это то, чего ему очень не хватало. А еще не хватало информации, поэтому он с восторгом принял лозунг «Information must be free» («Информация должна быть свободной»), ведь корпорация АйГейпл ограничила доступ к техническим сведениям о сетевых протоколах, устройстве операционных систем и даже к языкам программирования за исключением iBasic.

Айбейсик годился лишь на обучение самым основам программирования типа вывода строки «Привет, мир!» или простейшего калькулятора. Что-то серьёзное написать на нём было невозможно. К тому же айбейсик-программы выполнялись лишь на том компьютере, где были написаны. Чтобы распространять программу, требовалось приобрести у АйГейпл лицензию разработчика, потом зарегистрировать программу в магазине приложений — за деньги, разумеется. Плата за регистрацию программы совсем не означала, что программа будет принята в магазин. Да и лицензию разработчика давали крайне неохотно после многочисленных проверок.

Ещё Ирвину не хватало учебников. В разделе «программирование» официального магазина АйГейпл присутствовали исключительно руководства по iBasic с издевательской пометкой «для профессионалов». Но и на их покупку денег у Ирвина всё равно не было.

Неудивительно, что LuxOS вместе с многочисленными книгами по программированию и документацией по операционным системам и сетевым протоколам, да ещё и с целой коллекцией компиляторов в комплекте, стала для Ирвина настоящим подарком. Он горячо поблагодарил отца и согласно кивнул, когда отец предупредил его о мерах предосторожности: никогда не работать с визуальным интерфейсом LuxOS за пределами комнаты, никому не рассказывать о том, что он узнал и самое сложное — никак не проявлять свой внезапно выросший уровень знаний.

Ирвин поглощал информацию с немыслимой быстротой. Его мозг словно был создан для этого. Сетевые протоколы и языки программирования — всё отпечатывалось в памяти с первого же прочтения. Уже через месяц он начал писать программы на Python — мощном языке программирования, который очень любили хакеры из-за огромного количества библиотек на все случаи жизни. Ещё он старательно изучал Stift — основной язык для разработки программ в TuneOS. Помимо программирования он вникал в устройство операционных систем и аппаратной платформы техники АйГейпл. Теперь Ирвин понимал, почему айбейсик казался ему таким примитивным.

Сетевые протоколы — набор правил, по которым все устройства в сети взаимодействуют между собой — поддались ему не сразу. Но упорное изучение документации сыграло свою роль. Скоро IPv4, IPv6, IPvX, — всё, о чём раньше Ирвин не имел ни малейшего представления, стали для него обыденностью. Он научился работать с сетевыми анализаторами и фильтрами пакетов, его программы оказывались намного эффективнее тех, что считались эталонными.

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

В один из дней Ирвин пришёл в лицей чуть раньше и уселся на место Кимбола. Это было больше, чем просто вызов: места в классе ученики лицея занимали в соответствии с негласным табелем о рангах, так что Ирвину всегда приходилось ютиться на самой задней парте.

Кимбол обычно приходил самым последним. Его имиджмейкер считал, что люди достойные никогда не приходят слишком рано. Их удел — появляться точно вовремя, чтобы плебс, пришедший заранее, с завистью наблюдал за их появлением.

Так было и в этот раз. За десять секунд до начала урока Кимбол появился на пороге класса. Увидев на своём месте Ирвина, он побагровел, но из-за недостатка времени ничего не смог сделать, так что ему пришлось занять место на последней парте.

Ирвин запустил программу-снифер собственной разработки и в течение урока с удовлетворением следил за злобными репликами Кимбола в общем чате класса. Раньше Ирвин не мог получить доступ к этому чату из-за ограничений скинекта. Зато сейчас он мог не только участвовать в общем разговоре от своего имени, но и написать сообщение от имени любого из одноклассников.

Напряжение в чате нарастало, и к концу урока достигло наивысшей точки. Когда мелодичный звук колокольчика пригласил учеников на перерыв, Кимбол вскочил, как ужаленный.

— Купер! Кто тебе позволил занять моё место!

— Кимбол, разве на этом месте висит табличка с твоим именем? Оно такое же твоё, как и моё, — спокойно ответил ему Ирвин.

— Ну, Купер, ты сам напросился, — злобно пропел Кимбол и подал знак своим прихвостням — Гилмору, Сеймуру и МакКарти. Обычно после этого над планоутом Ирвина появлялась какая-нибудь непристойная картинка. Выключить её у Ирвина не получалось, потому что его скинект уступал по возможностям скинектам одноклассников. В результате он весь день получал замечания от учителей и пониженный балл за поведение. Только в этот раз всё пошло не так.

После знака Кимбола ничего не произошло. Совсем. Троица подпевал усиленно мотала руками, пытаясь активизировать атакующую программу, но безуспешно. А потом над планоутами всех четверых засветились объёмные надписи «Я придурок». И все попытки агрессоров отключить эту надпись ни к чему не привели. Как и попытки учителя информатики, который появился к началу урока.

— Это всё Купер виноват, — пытался обвинить его Кимбол.

Но Ирвин лишь непонимающе пожимал плечами, мол какие дела, у меня скинект последний раз обновлялся восемь лет назад.

Чтобы избавиться от надписей, одноклассникам пришлось оплачивать замену прошивки скинекта. После этого случая Кимбол стал вести себя более осторожно, не проявляя прямой агрессии, но и не упуская случая как-нибудь съязвить в адрес Ирвина.

Разделавшись с обидчиками, Ирвин был разочарован. С одной стороны, он получил то, что хотел: к нему больше не цеплялись, и он мог спокойно учиться. С другой — он не только не испытал облегчения, а напротив, ощущал стыд из-за того, что так глупо использовал знания, полученные благодаря отцу. Поддавшись эмоциям, он сильно рисковал. Кто знает, к каким последствиям может привести его поступок в дальнейшем.

Он почувствовал себя обязанным сделать что-то важное и нужное для всех. Изменить мир, созданный корпорацией АйГейпл, дать всем по-настоящему равные возможности. Это чувство оформилось в цель, и он пришёл к пониманию того, что должен сделать. Он вернёт всем свободу, которую забрала АйГейпл в обмен на сытую и комфортную жизнь.

Каждый день Ирвина наполнился смыслом. По дороге в лицей и обратно он изучал документацию по внутреннему устройству мини-ОС, вчитывался в комментарии к программному коду, написанные отцом. Это так увлекало, что он с большим сожалением переключал планоут из секретного режима в обычный, когда скинект легкой вибрацией напоминал, что пора готовиться к выходу.

Учёба в лицее стала лишь досадной помехой в реализации планов Ирвина. Он по-прежнему получал хорошие оценки, ведь материал, который давали преподаватели, оказался жутко примитивен по сравнению с теми знаниями, которые он получал из учебников на секретном разделе своего скинекта. И самое главное — многие вещи оказались откровенной неправдой.

Первое, что следовало сделать, вернувшись из лицея домой, это взять свой ужин в автомате. Автомат-фидер был один, поэтому в завтрак и ужин к нему выстраивалась длиннющая очередь. Ирвин обычно стоял рядом с соседскими мальчишками-близнецами африканского происхождения. Чак и Боб, белозубые и жизнерадостные ребята, увлекались хип-хопом и баскетболом. Они развлекали стоящих в очереди, напевая на разные лады фрагмент очередной популярной песенки. Поскольку для того, чтобы услышать её целиком, нужна была платная подписка, продолжение песенки братья придумывали сами. Эти импровизации очень нравились всем соседям, и братья получали свою заслуженную порцию аплодисментов.

Ирвин как-то спросил у Чака, чего ему не хватает для счастья. Тот немного подумал и сказал: «Пожалуй, у меня есть всё, что нужно. Мне бы только ещё послушать, что там Айк Эм Си сочинил в своём новом альбоме, тогда я был бы вполне доволен!»

Получив свою порцию, Ирвин заходил домой, быстро ужинал, делал уроки и до поздней ночи работал над модвормом — модификацией системной прошивки скинекта со встроенным механизмом распространения. В процессе размножения модворм корректировал правила на сетевых фильтрах, сенсорах и маршрутизаторах. Совсем чуть-чуть, так, чтобы не сработала тревожная сигнализация.

Отлаживать модворм было очень сложно. Пришлось организовать целую ферму виртуальных машин внутри скинекта. Ресурсов не хватало, и даже «разгон» процессора помогал совсем немного. Браслет обжигал руку так, что было невозможно терпеть, но Ирвин заставлял себя не обращать внимания на боль. Ночью он забывался тревожным сном. Ему снился отец. Он о чём-то пытался его предупредить, но Ирвин никак не мог разобрать слова…

Через несколько месяцев напряжённой работы все баги в программе были отловлены, а набор функций получился даже богаче изначально запланированного. Виртуальные скинекты, маршрутизаторы, шлюзы и системы глубокой инспекции трафика покорно сдавались на милость модворма. Можно было запускать его на просторы Айнета и наблюдать за тем, как меняется мир.

Мальчик долго думал, в какое время лучше выпустить программу на свободу, и решил, что сделает это по дороге на занятия в день годовщины ареста отца. За час модворм распространится достаточно для того, чтобы это стало заметно. А это значит, что когда Ирвин зайдёт в лицей, большая часть его одноклассников уже будет иметь модифицированную мини-ОС в скинектах. Ещё через час модификация установится у всех жителей мегаполиса, а к концу дня все граждане АйГейпл получат полную свободу.

Модворм, написанный Ирвином, отключал механизмы слежения за пользователями и ограничения доступа к контенту. Фактически, он превратил жёстко регламентированный Айнет в свободную от ограничений сеть, которую мальчик про себя называл Фринетом.

Пользователи Фринета получали неограниченный бесплатный доступ к музыке, книгам и фильмам. Они могли делать всё, что угодно на своих скинектах, не опасаясь, что копирайт-полиция АйГейпл обнаружит какие-либо нарушения.

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

Двери вагона закрылись, скоростной экспресс бесшумно полетел над монорельсом. Ирвин глубоко вдохнул, зажмурился, а потом сделал особый жест тремя пальцами левой руки. «За отца!» — подумал он, медленно выдыхая. Модворм начал свою работу, взламывая и модифицируя прошивки всех устройств, оказавшихся в зоне его охвата.

Над раскрытым планоутом мужчины в строгом костюме в другом конце вагона появилась картинка видеоролика, запущенного модвормом. Мужчина задёргался, пытаясь остановить воспроизведение, но у него ничего не получилось. Дослушав ролик до конца, мужчина принялся оглядываться по сторонам с затравленным выражением лица, затем судорожно застучал по клавишам планоута. Постепенно его движения стали более плавными. Наконец, он успокоился, закрыл планоут, достал из кармана носовой платок, вытер лоб и стал смотреть в окно…

«Мимо цели», — подумал Ирвин, выходя из вагона.

В лицее царило оживление. Одноклассники обсуждали сообщение от партии Фринета — так Ирвин назвался в видеоролике. Обсуждение сводилось к тому, можно ли верить анониму, который пообещал всем свободу.

— А ты пробовал? — С раскрасневшимся лицом орал Кимбол на МакКарти. — Нет? А чего? Тоже боишься, что это проверка лояльности, устроенная копирайт-полицией? Вот то-то и оно! Проще заплатить и спать спокойно, чем загреметь под фанфары, как некоторые… — С опаской покосился он в сторону Ирвина.

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

Ирвин грустным взглядом проводил скоростной экспресс, с тоскливым воем унесшийся прочь. Квартал имени Марка Збиковски встретил его так, словно ничего не произошло. На качелях у серой коробки общежития катались дети, на пятачке асфальта с баскетбольным кольцом азартно стучали мячом Чак и Боб. У подъезда сидели старушки, возраст которых не позволял им переехать в дом престарелых.

— Привет, Ирвин! — махнул ему рукой Чак. — Ты сегодня рано. Отпустили пораньше?

— Привет, Чак… Да, отпустили, — пробормотал Ирвин. — Скажи, Чак, а ты получал сегодня сообщение?

— Какое сообщение? Ты про этот ролик от какого-то чудика, который сказал, что теперь всю музыку можно слушать бесплатно и по сколько хочешь раз. Мы с Бобом даже зашли и послушали новый альбом Айка. Чел реально качает, мы прониклись. Только потом, знаешь, как-то не по себе стало. Словно мы чужое берём… Но ведь мы не такие, верно я говорю, Боб?

Боб что-то пробурчал в подтверждение, мол, да, не такие мы, нам чужого не надо.

— Вот я и подумал, — продолжал Чак, — что лучше мы честно заработаем денег и купим альбом Айка. И тогда отожгём вместе с ним по полной, так ведь, Бобби?

У Ирвина не осталось сил стоять в очереди за едой. Да и есть совсем не хотелось. Он зашёл в свою конуру, откинул стол, раскрыл планоут, подключился к сети и прошёлся по новостным каналам в поисках сообщения о вирусе, но нашёл только пародию на свой ролик от юмористического портала. Тогда он запустил управляющий модуль модворма и проверил состояние.

Уровень охвата: 99,99% — модворм установился практически на все устройства, подконтрольные АйГейпл.

Обращений за свободным доступом: 0,01% — только один человек из десяти тысяч попробовал обратиться к «закрытому» прежде контенту.

Повторных обращений за свободным доступом: 0%.

Ирвин в отчаянии уронил голову на руки. Он едва сдерживал слёзы. Свобода оказалась никому не нужна.

Представьте картину. Разработчик Chromium меняет в исходниках одну строчку. Нажимает «собрать». Встаёт, идёт на кухню, заваривает чай. Возвращается — сборка всё ещё идёт. Линкер.

Это не анекдот. В 2020 году на среднем рабочем ноутбуке финальная линковка Chromium через GNU ld занимала около минуты. Через LLVM lld — около одиннадцати секунд. Казалось, что одиннадцать — это предельно быстро: Руи Уэяма, автор lld, потратил на эту цифру годы оптимизаций. Когда вы касаетесь маленькой функции в .cc-файле, компилятор пересобирает один-два объекта за полсекунды, а потом линкер — он не знает, что изменилась строчка — заново перечитывает все тридцать тысяч объектных файлов. Тридцать. Тысяч. И каждый раз проходит по всей программе от начала до конца.

В июне 2021 года этот же Руи Уэяма выкладывает на GitHub новый проект — mold. И линкует Chromium за две секунды.

Точные числа из его бенчмарков на 12-ядерной машине:

Reddit, Hacker News, внутренние чаты Google и Meta просто взрываются. В двадцать пять раз. Не на двадцать пять процентов, а в двадцать пять раз. Без волшебства, без читов, на тех же файлах, на том же железе.

Больше половины комментариев под первой новостью — вариации одной и той же фразы: «А что, линковка вообще может быть такой быстрой?». Это и есть главный симптом проблемы, о которой мы поговорим. Линкер — невидимый, «последний этап», про который никто не думает. Компилятор мы обсуждаем часами (SSA, register allocation, optimization passes). Линкер — просто пробел между сборкой и запуском.

А ведь от него зависит всё: автономен ли бинарник, запустится ли он на соседнем сервере, сколько времени уходит на cargo build, возможна ли кросс-компиляция без мучений с sysroot, заработает ли Docker-образ размером в пять мегабайт. Эта статья — про тихого диктатора, без которого невозможен ни один запущенный исполняемый файл на вашей машине. С разбором PLT/GOT, с историей от EDSAC до Wild, с кодом на Rust, Go, Zig и Nim.

Часть 1. Почему линкер вообще нужен

Игрушечная модель vs реальность

Представьте, что вся ваша программа — один файл на 200 строк. Компилятор читает этот файл, генерирует машинный код, оборачивает его в заголовок исполняемого файла (ELF, Mach-O, PE/COFF — смотря какая ОС), и готово. Линкер как будто не нужен.

Но в жизни так не бывает. Ядро Linux — 36 миллионов строк кода. Chromium — 35 миллионов. LLVM — 10 миллионов. Ваш Cargo-проект со всеми зависимостями запросто набирает пару миллионов через serde, tokio, reqwest. Скомпилировать эту громаду одним куском означает ждать часами каждый раз, когда вы меняете одну строку.

Ровно для этого в 1950-х придумали раздельную компиляцию: каждый исходник превращается в полуфабрикат — объектный файл. В нём уже машинный код, но он ещё не знает, где находятся функции из других файлов. Ссылки на них — «дырки», заполненные нулями с пометкой «сюда вставить адрес printf, когда он станет известен». Эти полуфабрикаты собирает в единое целое линкер.

Объектный файл — это, по сути, машинный код с дырками. Линкер эти дырки заклеивает. Если за час работы вы меняете два файла, компилятор пересобирает два объектных файла (секунды), а линкер быстро пересобирает финальный бинарник из свежих и старых объектников.

Что реально лежит внутри объектного файла

Возьмём для примера самый простой случай. Файл math.nim:

proc square*(x: int): int = x * x
proc cube*(x: int):   int = x * square(x)

Nim транслирует это в C, GCC/Clang компилирует в math.o. Посмотрим внутрь:

• Секция .text — машинный код функций square и cube. Это собственно программа.
• Секция .rodata — read-only data: строковые литералы, константы, таблицы.
• Секция .data — инициализированные глобальные переменные.
• Секция .bss — нулевые глобалки (в файле не хранятся, только «зарезервировать N байт»).
• Таблица символов .symtab — список имён с адресами: «функция square начинается по смещению 0x10, имеет размер 0x24 байта, локальная/глобальная видимость, такого-то типа».
• Таблица релокаций .rela.text — самое интересное. Для каждой «дырки» в коде здесь запись: «по смещению 0x37 в .text подставить адрес символа square, относительный, 32-битный».

Вот как посмотреть это на реальном бинарнике:

nm ./link_demo | head -5      # таблица символов
#  0000000100004000 d _nim_program_result
#  00000001000015f0 T _NimMainInner
#  00000001000015a0 T _NimMain
#  000000010000cf70 t _my_add       ← наша функция, экспортированная
#  000000010000d370 T _main
readelf -r math.o              # релокации
objdump -d math.o              # дизассемблер

В nm буква T означает «экспортированный символ в секции кода». Маленькая t — локальный (не виден снаружи). D и B — глобальные переменные. U — undefined, то самое «меня нет в этом файле, линкер, найди меня где-нибудь ещё».

Три задачи линкера

Формально линкер решает ровно три задачи. Всё остальное — разнообразие реализаций.

1. Разрешение символов (symbol resolution). Линкер берёт все объектные файлы и все указанные библиотеки, строит глобальную таблицу: какой символ где живёт. Для каждого U-символа нужно найти соответствующий T или D в каком-то другом файле. Нет подходящего — знаменитая ошибка undefined reference to 'foo'. Нашёл два определения одного символа — multiple definition of 'foo'.

Есть ещё слабые символы (weak) — особый тип, который позволяет «вот моё определение, но если найдёшь сильное — бери его». Слабые символы используются для переопределения operator new в C++ или замены malloc на jemalloc/tcmalloc. Здесь линкер из арбитра превращается в дипломата.

2. Размещение (relocation). После того как все символы найдены, нужно дать каждой секции код и данных окончательный виртуальный адрес. .text — в 0x401000, .data — в 0x402000 и так далее. Затем линкер проходит по таблицам релокаций и подставляет настоящие адреса в «дырки».

В зависимости от архитектуры релокации бывают абсолютные (вставить полный 64-битный адрес), относительные к PC (смещение от текущей инструкции), GOT-относительные, TLS-относительные и ещё с пару дюжин разновидностей. Только для x86-64 в ELF описано около 40 типов релокаций.

3. Формирование выходного файла. Склеить всё в формат, понятный операционной системе. На Linux — ELF, на macOS — Mach-O, на Windows — PE/COFF, в браузере — WASM. Форматы разные, идея одна: таблица секций плюс программные заголовки, которые говорят загрузчику «вот это положи в память по такому-то адресу с такими-то правами доступа».

Звучит прозаично. Но за каждой из трёх задач — полвека инженерных войн и дюжина тонких нюансов, которые определяют, будет ли ваш бинарник работать на соседнем сервере.

Часть 2. Семь десятилетий истории

1949: Дэвид Уилер изобретает подпрограмму и линковку

История линкеров начинается не с ENIAC и не с IBM. Она начинается в Кембридже. В мае 1949 года там запустили EDSAC — электронную машину с хранимой программой. И практически сразу Дэвид Уилер, молодой аспирант (позднее — соавтор шифра блочного шифрования Feistel и один из создателей операционной системы CAP), столкнулся с очевидной проблемой: одни и те же куски кода — вычисление синуса, печать числа, ввод данных с ленты — переписываются в каждой программе заново. Руками. С пересчётом всех адресов переходов.

И Уилер придумал две вещи, которые определили всю компьютерную науку дальше.

Первая вещь — подпрограмма. Уилер изобрёл механизм «вызвать блок кода и вернуться обратно» и придумал название для него — subroutine. Именно его инструкция перехода с сохранением обратного адреса получила имя Wheeler jump. Это то, что сегодня мы называем call/ret.

Вторая вещь — линковка. Уилер написал программу, которая называлась initial orders: крошечный загрузчик на одной перфоленте, который читал с другой ленты основную программу, находил в ней «адресные метки», подставлял реальные адреса подпрограмм и клал всё в память. Это первый в мировой истории линкер. Он работал на ЭВМ с 512 словами памяти. За это Уилер позже получил премию Тьюринга.

1952: Грейс Хоппер и слово «библиотека»

В 1952 году Грейс Хоппер — будущая контр-адмирал флота США и крёстная мать COBOL — создаёт A-0 System, один из первых трансляторов. Программист пишет на перфокартах номер нужной подпрограммы, A-0 находит её на магнитной ленте, переписывает в программу и правит все адреса. Полноценный линкер, написанный в 1952 году на одной из первых коммерческих ЭВМ.

Именно отсюда пошло слово «библиотека». Команда Хоппер держала набор готовых подпрограмм на магнитных лентах, физически в шкафу, как книги на полке. Сотрудник подходил, брал нужную ленту, загружал её в машину. Сотрудница назвала эти ленты library — и название пережило 70 лет, перфоленты, саму Хоппер, COBOL и почти всех, кто это видел своими глазами.

1960-е: IBM OS/360, линкер и загрузчик расходятся

В IBM OS/360 впервые появляется каноническое разделение, которое живёт до сих пор:

• Линкер — собирает из объектных файлов единый исполняемый модуль на диске.
• Загрузчик (loader) — берёт готовый модуль и кладёт его в память при запуске.

Книга Джона Левайна «Linkers and Loaders» 1999 года, которая до сих пор считается главной энциклопедией в этой предметной области, называется именно так не случайно: это две разные сущности, которые делают очень похожую работу в разные моменты времени.

1970-е: Кен Томпсон пишет ld для Unix

В первых версиях Unix появляется утилита ld — link editor. Написал её Кен Томпсон. С тех пор на всех Unix-системах линкер по умолчанию называется просто ld, и это прямое наследие тех времён. Формат объектных файлов — a.out, примитивный и приземлённый (тот же формат дал имя стандартному выходному файлу компилятора: a.out — и сегодня, если забыть -o, вы получите файл с этим именем).

1988: в AT&T рождается ELF

К концу 1980-х a.out и COFF (Common Object File Format) трещат по швам: нужна нормальная поддержка разделяемых библиотек, debug-информации, многих архитектур. В 1988 году AT&T System Laboratories публикуют ELF — Executable and Linkable Format. Элегантный, расширяемый, одинаковый для объектников и исполняемых файлов. В 1995 году Linux окончательно переходит на ELF, вслед за ним FreeBSD, Solaris, и ELF становится негласным стандартом всех Unix-систем, кроме macOS.

1990-е: рождение DLL Hell

Windows 95, эра CD-ROM, «установите программу — 12 дискет». Системные DLL лежат в одной папке. Установка одной игры может заменить msvcrt.dll на свою, несовместимую с другими приложениями, версию. На форумах появляется термин DLL Hell и становится мемом. Microsoft отвечает пакетной артиллерией:

• Windows File Protection (Windows 2000) — мешает заменять системные DLL.
• Side-by-Side Assemblies / WinSxS (Windows XP) — несколько версий одной и той же DLL могут сосуществовать в системе.
• Манифесты — каждое приложение указывает, какую версию библиотеки оно хочет.
• .NET GAC — Global Assembly Cache, своё решение в мире .NET.

В итоге — гигантская папка C:\Windows\WinSxS размером в десятки гигабайт, куда сложены все когда-либо установленные версии всех системных библиотек. DLL Hell стал управляемым. Но абсолютно неэлегантным.

2000-е: dependency hell в Unix

В Unix-мире происходит симметричная драма. Программа собрана под libssl.so.1.0.0, а в системе уже libssl.so.3. ABI изменилось, бинарник падает на старте с undefined symbol: EVP_md5. Появляются пакетные менеджеры: apt, rpm, pacman, portage, позднее nix. Они решают проблему — пока вы внутри одного дистрибутива одной версии. Как только нужно взять бинарник, собранный на Ubuntu 20.04, и запустить на CentOS 7 — добро пожаловать в знаменитое /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.28 not found.

2013-2014: Docker меняет всё

Соломон Хайкс выкладывает Docker. Через полгода за ним подтягивается Kubernetes. Философия «упакуйте приложение со всей своей ОС» даёт ответ dependency hell на уровне совершенно иной абстракции — зачем решать проблемы с линковкой, если можно просто запечатать их в контейнер?

Но контейнер размером 800 МБ ради одного 12-мегабайтного Go-бинарника раздражает. И здесь приходит Go со своей статикой по умолчанию: бинарник без единой внешней зависимости, контейнер FROM scratch, общий размер образа — пять мегабайт. Маятник истории возвращается к статике.

2021-2025: гонка линкеров выходит на новый виток

Руи Уэяма пишет mold. Meta анонсирует Wild на Rust. Apple переходит на свой новый линкер в Xcode 15. wasm-ld становится стандартом для WebAssembly-компонентов. После тридцати лет спокойной эволюции линкеры снова оказываются полем активной инновации.

Часть 3. Статика vs динамика: вечный идеологический спор

Это главный водораздел в мире сборки. Если не понимаете разницу, не поймёте ничего дальше.

Статическая линковка

Весь код библиотек физически вшивается в ваш бинарник. Линкер берёт libssl.a (архив объектных файлов), вытаскивает оттуда только нужные функции и подставляет их прямо в ваш .text. На выходе один файл, который можно скопировать на пустой Alpine Linux без единой библиотеки, и он запустится.

Преимущества на практике:

• Предсказуемость. Собралось — работает. Сегодня. Завтра. В 2035 году, если процессор выживет.
• Простейший деплой. scp binary server:/usr/local/bin/ — всё. Никаких зависимостей, никакой установки.
• Иммунитет к DLL Hell. Версия библиотеки зацементирована в бинарнике навсегда.
• Старые бинарники работают. Статически собранный бинарник 2008 года запустится на современном ядре Linux.
• Проще профилирование. Все символы в одном файле, все инлайны видны, вся программа анализируется как единое целое.

Недостатки:

• Размер. Если сто программ в системе линкуют libc статически — в памяти сто копий libc. На современных машинах с терабайтом RAM это не драматично, но 30 лет назад это было катастрофой.
• Обновление безопасности — пересборка. Нашли дыру в zlib → пересобрать всё, что её использует. Сорок приложений → сорок пересборок. Компилятор пакетного менеджера не помогает.
• Лицензионные проблемы с LGPL. Библиотеки под LGPL (включая сам glibc) формально требуют возможности пересобрать приложение с новой версией библиотеки. Статическая линковка это блокирует. Поэтому glibc статически линковать юридически нельзя — musl подставили как выход.

Динамическая линковка

Ссылка на библиотеку остаётся в бинарнике как обещание: «когда меня запустят, найди libssl.so.3, подгрузи в память, подставь реальные адреса». Загрузчик ОС (/lib64/ld-linux-x86-64.so.2 на Linux, dyld на macOS, ntdll.dll на Windows) делает это при запуске программы.

Преимущества:

• Экономия памяти. Одна копия библиотеки на всю систему. Физические страницы libc разделяются между всеми процессами через mmap.
• Обновления через пакетный менеджер. apt upgrade libssl — и все программы в системе сразу используют пропатченную библиотеку.
• Плагины. dlopen() позволяет загружать код в рантайме. Это VST-плагины, расширения редакторов, драйверы устройств.
• Меньший размер бинарников. Ваша программа — 200 КБ, libc — где-то в системе.

Недостатки:

• Хрупкость. Несовместимое обновление библиотеки ломает всё, что от неё зависит.
• Медленный старт. Динамический загрузчик может резолвить сотни символов. На тяжёлых программах это миллисекунды или десятки миллисекунд.
• Сложный деплой. «Работает на моей машине» — это в 9 случаях из 10 про динамическую линковку.
• Surface для атак. LD_PRELOAD, GOT overwrite, DLL hijacking — целая коллекция техник злоупотребления динамической линковкой.

Маятник истории

В 1990-е динамическая линковка казалась абсолютным будущим. Экономия RAM, централизованные обновления безопасности, плагинные архитектуры — казалось, статическая линковка уйдёт в музей вместе с перфокартами.

В 2014 случился Heartbleed. Критическая дыра в OpenSSL. Динамически слинкованные системы спаслись одним apt upgrade openssl. Статически слинкованные нужно было пересобрать полностью. Каждую программу. Это казалось победным аргументом за динамику.

Но дальше пришёл Docker, пришёл Go, и в 2020-х маятник резко качнулся обратно. Контейнер решает проблему обновлений: пересобираем образ, катим в прод, старый удаляется. Размер 5 МБ против 800 МБ статической Ubuntu внутри контейнера — очевидное преимущество статики. Go сделал статику по умолчанию. Rust, собранный с target x86_64-unknown-linux-musl, — тоже. Zig — тем более. Nim — при желании.

Сегодняшний консенсус где-то посередине:

• Системные утилиты — динамическая линковка, легко обновляются пакетным менеджером.
• Приложения на разделяемых хостингах — по традиции динамическая.
• Приложения в контейнерах — всё чаще полностью статические.
• CLI-утилиты, которые скачивают как бинарник (rg, fd, hyperfine, bat) — статика, один файл.
• Браузеры, игры — динамическая (огромные размеры, большие объёмы кода).

Принцип выбора простой: если вы распространяете программу отдельно — статика. Если она устанавливается в составе ОС — динамика.

Часть 4. Анатомия ELF: что на самом деле в бинарнике

Пора залезть внутрь. Все Linux-примеры будут про ELF, но концепции одни и те же для Mach-O и PE/COFF — меняются только имена.

Сегменты и секции

В ELF есть две параллельных «карты» файла:

• Секции (sections) — то, что видит линкер. .text, .data, .rodata, .bss, .symtab, .strtab и ещё с пару десятков. Удобно для сборки.
• Сегменты (segments) — то, что видит загрузчик ОС. Один сегмент LOAD для кода (read+execute), один LOAD для данных (read+write), INTERP с путём к динамическому загрузчику, DYNAMIC со служебной информацией о рантайм-линковке. Удобно для отображения в память.

Один сегмент LOAD обычно покрывает несколько секций — например, .text, .rodata и .plt все попадают в один read+execute сегмент.

Ключевые секции

Каждая из этих секций — отдельный мир со своими правилами, форматом и назначением. .eh_frame, например, — сложнейший формат на основе DWARF, который описывает, как на каждой инструкции программы восстановить регистры и найти обработчики исключений. Когда в Go или Rust падает паника и вы видите красивый stack trace — это работает .eh_frame плюс отладочная информация.

DT_NEEDED, RPATH, RUNPATH: как программа находит свои библиотеки

Секция .dynamic — табличка, которую читает загрузчик при запуске. Записи DT_NEEDED перечисляют, какие библиотеки нужны:

readelf -d ./my_program | grep NEEDED
# 0x0000000000000001 (NEEDED)  Shared library: [libssl.so.3]
# 0x0000000000000001 (NEEDED)  Shared library: [libcrypto.so.3]
# 0x0000000000000001 (NEEDED)  Shared library: [libc.so.6]

Когда ОС запускает программу, первым в память загружается не сам бинарник, а указанный в .interp динамический загрузчик (ld.so). Он и делает всю работу:

1. Читает DT_NEEDED — список нужных библиотек.
2. Ищет каждую по алгоритму:
• LD_PRELOAD (переменная окружения — принудительные библиотеки).
• DT_RPATH (если есть — устаревшее).
• LD_LIBRARY_PATH (переменная окружения).
• DT_RUNPATH (новое, заменило RPATH).
• /etc/ld.so.cache (построенная ldconfig таблица всех известных библиотек).
• /lib и /usr/lib (стандартные пути).
3. Отображает каждую найденную .so в память через mmap.
4. Разрешает все недостающие символы.
5. Вызывает конструкторы (DT_INIT, DT_INIT_ARRAY).
6. Передаёт управление _start вашего бинарника.

Порядок поиска критичен для безопасности. Если программа ставится с RUNPATH=./, злоумышленник подсовывает в текущую директорию свою libssl.so.3 — и ваша программа загружает чужой код с правами пользователя. Это называется DLL hijacking и давно перестало быть теоретическим.

LD_PRELOAD: светлая и тёмная стороны

LD_PRELOAD=/path/to/my.so ./program — заставляет загрузчик подгрузить указанную библиотеку до всех остальных. Символы из неё имеют приоритет. Это чудесная вещь:

Светлая сторона:

• Профилирование. LD_PRELOAD=libprofiler.so — оборачиваем все malloc/free для сбора статистики памяти.
• Трассировка сети. tsocks, proxychains подменяют connect(), чтобы направить трафик через прокси.
• jemalloc / tcmalloc. Подменить системный malloc на более быстрый — одна строчка переменной окружения, без пересборки.
• Отладка. LD_PRELOAD обёртки для поиска утечек, гонок данных (ThreadSanitizer, Valgrind частично).

Тёмная сторона:

• Rootkit’ы. Подменяете readdir() — и ваша директория становится невидимой для ls. Подменяете write() — и логи не пишутся. Классика malware в Linux.
• Обход проверок. Подменяете getuid() на «всегда 0» — и многие программы думают, что их запустили от root.

Именно поэтому LD_PRELOAD в SUID-программах отключена. И именно поэтому в модных нынче безопасных системах (Android, iOS) — никакого LD_PRELOAD нет в принципе.

Symbol versioning: как glibc убивает ваши бинарники

Вот вам почти детективная история.

Вы собираете бинарник на Ubuntu 22.04 (glibc 2.35) и пытаетесь запустить на Debian 10 (glibc 2.28). Ошибка:

./mybin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found
./mybin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found

Почему так? Ведь memcpy был в glibc со времён динозавров, за что ошибка?

Разгадка в том, что glibc использует symbol versioning. Когда поведение функции меняется (например, добавили флаг или поправили недокументированное поведение), GNU не ломает ABI, они создают новую версию того же символа. Теперь в libc есть одновременно:

• memcpy@GLIBC_2.2.5 — старая.
• memcpy@GLIBC_2.14 — новая, с другой семантикой перекрытий буферов.

Когда вы собираете на Ubuntu 22.04, линкер выбирает memcpy@GLIBC_2.14. Когда вы запускаете на Debian 10 с glibc 2.28, там эта версия есть. А вот если где-то в вашем коде glibc вставила вызов символа, появившегося в 2.32 или 2.34, — финиш. Даже если вы никогда не звали эту функцию явно; она могла вылезти из какой-нибудь fprintf или pthread_create.

Обходные пути:

• musl libc — без symbol versioning, без этой драмы.
• Сборка на старой системе — Docker-образы с древним glibc.
• cargo-zigbuild — использовать zig cc как линкер, он умеет прицеливаться в glibc определённой версии.
• Статическая линковка всей libc (практически возможно только с musl).

Часть 5. PLT и GOT: магия ленивой линковки

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

Проблема

Ваш бинарник вызывает printf. В момент компиляции и линковки вы не знаете, где в памяти будет printf, потому что:

1. Libc загрузится по произвольному адресу (ASLR — рандомизация).
2. Бинарник может быть PIE (Position Independent Executable) — он сам не знает, куда его загрузили.

Как же на инструкции call printf подставить адрес?

Решение: два уровня непрямой адресации

Компилятор генерирует вызов не напрямую, а через два промежуточных слоя:

• GOT (Global Offset Table) — таблица указателей на реальные адреса внешних символов. Заполняется динамическим загрузчиком.
• PLT (Procedure Linkage Table) — массив маленьких «батутов». Каждая запись — 4-5 инструкций, которые делают косвенный переход через соответствующую ячейку GOT.

Когда ваш код делает call printf, на самом деле он вызывает printf@plt. Посмотрим, что внутри:

printf@plt:
    jmp    QWORD PTR [rip + printf@got]   ; переход по адресу из GOT
    push   0x0                            ; индекс символа
    jmp    _dl_runtime_resolve            ; вызвать резолвер

А в GOT для printf изначально лежит… обратный адрес в PLT (на следующую инструкцию после jmp). То есть при первом вызове:

1. Код: call printf@plt.
2. PLT: jmp [printf@got] — но там пока обратный адрес.
3. PLT продолжает: push индекса и jmp _dl_runtime_resolve.
4. Резолвер находит настоящий адрес printf в libc, записывает его в GOT и передаёт туда управление.
5. printf выполняется и возвращается.

При втором и всех последующих вызовах:

1. Код: call printf@plt.
2. PLT: jmp [printf@got] — там уже настоящий адрес.
3. Сразу в printf.

Вся машинерия резолвинга проскакивается одним переходом. Это называется lazy binding — ленивое связывание. Великое изобретение конца 80-х, позволяющее быстро стартовать программы, которые линкуют тысячи символов, но реально используют десятки.

Минус ленивости: атака GOT overwrite

Но тут есть проблема. GOT по умолчанию записываемая память, ведь загрузчик должен в неё писать. А если писать в GOT может загрузчик, то и ваш эксплойт тоже может.

Классическая атака: злоумышленник через buffer overflow получает write primitive, переписывает запись для system@got или exit@got, и при ближайшем вызове ваша программа любезно передаёт управление в shell-код. Вариация, известная как ret2plt, помогла обойти ранние версии ASLR.

RELRO и BIND_NOW: защита от GOT overwrite

Ответ индустрии — две опции линкера:

• RELRO (Read-Only Relocations) — после того, как загрузчик заполнил GOT, пометить её как read-only через mprotect. Злоумышленник больше не может писать.
• BIND_NOW — не лениться, резолвить все символы сразу на старте. Медленнее на ~50 мс у большой программы, но GOT полностью готова к моменту запуска main.

Полная защита называется Full RELRO и включается одновременно обе опции:

gcc -Wl,-z,relro -Wl,-z,now  program.c

В современных Linux (Ubuntu, Fedora, Debian) это дефолт для всех системных бинарников. В Go, Rust, Zig при релиз-сборках — тоже по умолчанию. Проверить можно checksec:

RELRO           STACK CANARY   NX      PIE      RPATH    Symbols
Full RELRO      Canary found   NX      PIE      No RPATH No Symbols

Нюанс про производительность

Есть интересный компромисс: Full RELRO замедляет старт программы на 10-100 мс (надо резолвить тысячи символов сразу). Для долгоживущих процессов (веб-сервер, демон) это копейки. Для консольных утилит, которые запускаются миллион раз в день в скриптах (grep, cat), — ощутимо. Поэтому утилиты из GNU coreutils собираются с Partial RELRO — GOT остаётся записываемой, но другие защитные меры включены. Компромисс между безопасностью и скоростью старта.

Часть 6. Удаление мёртвого кода и идентичных функций

Не всё, что компилятор скормил линкеру, попадает в финальный бинарник. Современные линкеры активно удаляют балласт, причём иногда агрессивнее, чем вы ожидаете.

Секция per function: -ffunction-sections

По умолчанию компилятор складывает весь код одного .c-файла в одну секцию .text. Линкер не может удалить отдельную функцию, не поломав позиции других — они все в одной секции.

Флаги -ffunction-sections и -fdata-sections заставляют компилятор класть каждую функцию в свою секцию (.text.my_func, .text.another_func), а каждую глобалку — в свою. Теперь линкер может оперировать функциями по отдельности.

Garbage collection секций: --gc-sections

С -Wl,--gc-sections линкер находит все достижимые секции, стартуя с main (или нескольких явных корней — например, точек входа DSO), и выбрасывает всё, до чего не добрался. Точно как сборщик мусора в рантайме, только на уровне линковки.

На практике это даёт 10-30% сокращения бинарников из C/C++. В Rust включено по умолчанию. В Go собственный линкер делает DCE в ещё более тонкой гранулярности — на уровне отдельных символов внутри секций. Nim через бэкенд C получает это бесплатно.

Identical Code Folding: --icf

LLD и mold поддерживают ещё одну оптимизацию: ICF (Identical Code Folding). Линкер ищет функции, которые скомпилировались в абсолютно одинаковый машинный код, и оставляет только одну копию, а остальные делает её алиасами.

Кажется, что это редкая ситуация. Но на деле C++ и Rust генерируют тонны идентичных функций через шаблоны и генерики. Vec<u32>::push и Vec<i32>::push на уровне машинного кода могут быть неразличимы. ICF их схлопывает в одну. На Chromium это экономит около 10% размера .text.

Включается: -Wl,--icf=all (lld, mold). В Rust добавляется через:

[profile.release]
strip = true
lto = "thin"
# ICF включается автоматически при strip + lto на lld/mold

Гендерные и вуду-эффекты

Одна из дивных шуток ICF: если две функции идентичны по коду, но идеологически разные (fire_missile и print_warning), их адреса после ICF совпадают. Код типа if (fn_ptr == &fire_missile) может начать работать не так, как вы ожидали. Флаг --icf=safe пытается учитывать сравнения адресов функций, но это остаётся тонкой гранью.

Часть 7. Гонка линкеров: кто, когда и зачем

GNU ld (он же ld.bfd)

Самый распространённый линкер в мире Unix. Написан на C, использует библиотеку абстракций BFD (Binary File Descriptor), которая поддерживает около 70 разных форматов и 50 архитектур — от VAX до z/Architecture.

BFD — и благословение, и проклятие одновременно. Благословение — GNU ld собирает всё и под всё. Проклятие — BFD настолько многослойная, что добавляет огромный оверхед. Плюс линкер однопоточный. С Chromium разбирается почти минуту. Но для 99% мелких проектов этого хватает и никто не жалуется.

GNU gold (2008)

Иэн Тейлор из Google пишет новый линкер ELF на C++. Выбрасывает BFD, фокусируется только на ELF и нескольких архитектурах. В 5 раз быстрее GNU ld. Был включён в binutils в 2008 году.

Gold был прорывом своего времени, но к 2020 году развитие фактически остановилось. Тейлор ушёл из Google, в binutils его никто не заменил, параллельно LLVM делал lld, и интерес сообщества сместился туда. В 2024 году Fedora начала обсуждать удаление gold как не поддерживаемого.

LLVM lld (2015+)

Руи Уэяма, бывший инженер Google, начинает в LLVM новый проект — универсальный линкер. Ключевые цели:

• Кросс-линкер по умолчанию. Одна сборка lld линкует и ELF, и PE/COFF, и Mach-O, и WASM. На практике это четыре разных «фронтенда» под общим именем: ld.lld, lld-link, ld64.lld, wasm-ld — одна кодовая база, четыре бинарника.
• Минимализм кода. LLD — 21 тысяча строк C++ против 198 тысяч у gold. Проще читать, проще менять, проще находить баги.
• Быстрее всего что было. В 2+ раза быстрее gold, параллельный, кэш-дружелюбный.
• LTO из коробки. Нет отдельной логики для thinLTO — это первоклассная фича.

LLD стал дефолтом во FreeBSD (2018), дефолтом для Chrome OS, дефолтом в Android NDK. Rust на Windows использует lld-link вместо MSVC-линкера. На Apple Silicon всё больше проектов уходят на ld64.lld вместо системного. LLD — новая норма везде, кроме консервативного GNU-мира.

mold (2021): а можно ещё быстрее?

Через несколько лет работы над lld Уэяма задаёт себе вопрос: а что, если бы я писал линкер сейчас, с нуля, зная всё, что знаю? Так родился mold.

Ключевые идеи, которые сделали его настолько быстрым:

1. Максимальный параллелизм на каждой фазе. Lld имеет последовательные фазы между параллельными блоками. Mold пытается делать параллельно всё что можно.
2. Lock-free структуры данных. Хэш-таблицы символов используют атомарные операции вместо мьютексов.
3. Mmap вместо read. Объектные файлы отображаются в память, без копирования.
4. Mmap выходного файла. Mold создаёт пустой файл нужного размера через ftruncate, мэпит его и пишет напрямую через массивы в памяти — ядро само отправит грязные страницы на диск в фоне, часто уже после завершения линкера.
5. Оптимизированные парсеры ELF. Написанные с учётом cache line размеров.
6. Инкрементальная фаза --thinlto-* — максимально параллельная обработка IR в ThinLTO.

Результат на Chromium (2.1 ГБ входных данных, 30 тысяч объектных файлов, 500 тысяч символов):

• GNU ld: 53,86 с.
• gold: 12,96 с.
• lld: 11,03 с.
• mold: 2,09 с.

Один инженер. Один репозиторий. 26-кратное ускорение против GNU ld. Это тот случай, когда «хорошие инженерные решения» звучит слишком скромно — это переосмысление задачи с чистого листа.

Интересный поворот лицензии: изначально mold вышел под AGPL (коммерческая лицензия, запрещающая SaaS-замыкание). Одновременно Уэяма делал платный порт для macOS под названием sold — за 100 долларов лицензии на машину. В 2024 году он перевёл и mold, и sold под MIT и полностью открыл код. Mold стал стандартом де-факто для ускорения Rust-сборок.

Wild (2024-2025): линкер на Rust

Meta анонсирует Wild — экспериментальный линкер на Rust от Дэвида Латтимора. Цели:

• Первоклассная инкрементальная линковка: перелинковывать только изменившиеся части бинарника. Это то, о чём давно мечтали все, но никто не сделал нормально — mold, lld делают inкрементальность крайне ограниченно.
• Hot reload в перспективе: менять работающую программу на лету.
• Проверить, даст ли Rust выигрыш в безопасности и параллелизме для инструмента такого масштаба.

Wild на ранних бенчмарках близок к mold по скорости и на некоторых сценариях обгоняет благодаря инкрементальности. Проект молодой (2024), но активно развивается.

Apple ld-prime (Xcode 15, 2023)

Пока мир смотрел на mold в Linux, Apple тихо переписывала свой линкер для macOS. В Xcode 15 появился новый ld, примерно в 5 раз быстрее старого на типовых проектах Swift/Objective-C. Детали не публиковались, но из дизассемблирования инженеры реверсят: параллелизм, mmap, кэширование — те же идеи, что в mold, без прямого упоминания mold.

Сводная таблица

Цифры — приблизительные и сильно зависят от проекта. Соотношение между линкерами сохраняется на большинстве больших C++/Rust-проектов.

Часть 8. Оптимизации после компиляции: LTO, PGO, BOLT

В классическом пайплайне каждый .c-файл компилируется отдельно, и компилятор видит только его содержимое. Оптимизатор не может заинлайнить функцию из соседнего файла, не может выбросить неиспользуемую глобальную переменную, не может девиртуализовать вызов через границу модуля. Современные тулчейны взламывают эту изоляцию тремя способами.

LTO: видеть всю программу одним куском

Link-Time Optimization — компилятор вместо машинного кода выдаёт промежуточное представление (LLVM IR у Clang/Rust, GIMPLE у GCC, свой формат у Nim). Линкер собирает всё это IR, вызывает оптимизатор на всей программе как на единой трансляционной единице, и только потом из IR получается машинный код.

Fat LTO. Весь IR грузится в одну гигантскую единицу компиляции. Максимально агрессивные инлайны, выбрасывание мёртвого кода на всю программу, девиртуализация виртуальных вызовов. Платите вы памятью: на проекте в сотни мегабайт IR оптимизатор может съесть 30 ГБ RAM и думать полчаса. Это норма.

Thin LTO (LLVM, 2016). Каждый модуль оптимизируется отдельно, но с доступом к сводке (summary) других модулей — краткой информации: имена функций, их размеры, ссылки на внешние символы. Параллельно. Медленнее Fat LTO в 3-5 раз (на финальной скорости кода), но требует в 10 раз меньше памяти и работает в разы быстрее. Thin LTO — разумный компромисс для подавляющего большинства продовых сборок.

В Rust LTO включается парой строк в Cargo.toml:

[profile.release]
lto = "thin"           # или "fat", или true
codegen-units = 1      # обычно с LTO ставят 1 единицу кодогенерации
strip = true           # попутно убираем debug-инфу

Разница на реальных проектах: прирост скорости кода 5-20%, но время сборки вырастает в 2-4 раза. Для ежедневной разработки — отключено. Для CI с релизными артефактами — включено.

PGO: компилятор учится на профиле

Profile-Guided Optimization — двухфазная сборка:

1. Собираете «инструментированный» бинарник (-fprofile-generate), который сам собирает профиль выполнения.
2. Гоняете его на типичных нагрузках. Получаете файлы профилей: какие ветки как часто срабатывают, какие функции горячие.
3. Пересобираете с -fprofile-use=profiles/ — компилятор использует эти данные для решений.

Что он оптимизирует с профилем? Размещение функций (горячие — рядом), порядок базовых блоков (ветка «с лайком» до ветки «без лайка»), inline-эвристики (если функция вызывается редко — не инлайнить, экономя icache), индирект-вызовы через виртуалки. Типовой прирост — 10-15% скорости. Clang сам собирается через PGO, Firefox собирается через PGO, браузеры Chromium — через PGO.

AutoFDO (Google) — вариация без инструментирования. Собираете обычный бинарник, запускаете под sampling-профилировщиком (Linux perf), получаете профиль в другом формате, компилятор его тоже понимает. Главный плюс — профиль снимается с продакшена.

BOLT: пост-линковочная оптимизация

В 2016 году Facebook выкатывает BOLT — Binary Optimization and Layout Tool. Идея на грани фола: берём уже готовый бинарник, снимаем профиль perf, и пост-линковочно переставляем функции и базовые блоки внутри них по профилю. Никакой пересборки — только переупаковка готовых инструкций.

Зачем? Кажется, что PGO делает то же самое. Но между PGO и BOLT есть существенная разница: PGO работает на уровне IR до генерации машинного кода. BOLT — на уровне готового машинного кода и может видеть вещи, которые недоступны компилятору (например, фактическую компоновку кода после линковки со всеми LTO и прочим).

Реальные результаты у Facebook: HHVM (runtime для Hack/PHP) после BOLT работает на 7-10% быстрее, чем то же самое с агрессивным PGO. Clang сам себя собирает через pipeline LTO + PGO + BOLT. Google стали использовать BOLT для ядра Linux на серверах — инструкционный icache hit rate вырос настолько, что это ощутимо по общему потреблению CPU в дата-центре.

Минус BOLT в том, что он требует glibc определённой версии, стабильности формата, не работает на musl. И пользоваться им неудобно: один лишний шаг в CI. Но для топовой оптимизации серверного софта это безальтернативный инструмент.

Часть 9. WebAssembly: линковка, родившаяся в браузере

WASM — отдельная вселенная. Это не просто новая архитектура, здесь изначально другая философия работы с зависимостями.

Каждый WASM-модуль — это таблица импортов и экспортов. Вместо «компилируй и линкуй» — «упакуй, а хост даст тебе нужные функции». Хостом может быть браузер (где функции — это JS и Web API) или WASI-рантайм (где они — ограниченный системный API).

wasm-ld — часть LLD — делает следующее:

• Собирает несколько объектных .o-файлов (WASM-объектов) в один .wasm модуль.
• Строит таблицы импортов и экспортов.
• Обрабатывает релокации — у WASM есть свои типы, отличные от ELF.
• Поддерживает --export, --import-memory, --shared-memory для нестандартных сценариев.

Интересная деталь: динамическая линковка в WASM не стандартизирована до конца. Emscripten придумал свою схему (MAIN_MODULE/SIDE_MODULE) с собственными PLT-аналогами поверх JS-glue. WASI Component Model (2024-2025) строит совсем другую модель — композицию компонентов через WIT-интерфейсы. Это уже не линковка в классическом смысле, это пакетное связывание модулей с явными контрактами типов — ближе к Protocol Buffers, чем к .so.

Rust, Go, Zig, C/C++ — все умеют компилироваться в WASM через wasm32-unknown-unknown или wasm32-wasi target. Nim — через nimcache, собирая C-бэкенд в WASM через Emscripten. Тема настолько большая, что заслуживает отдельной статьи.

Часть 10. Языки и их линкеры

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

Go: собственный линкер по наследству от Plan 9

Go использует собственный линкер cmd/link, написанный на Go (с перегруппировкой после самобутстрапа в 2015). Это прямое наследие Plan 9 — операционной системы Bell Labs. Над Plan 9 работали Роб Пайк, Кен Томпсон, Дэннис Ричи — те же имена, что и в Unix. В Plan 9 был свой компилятор 8c/6c/5c и свой линкер 8l/6l/5l. Когда Пайк и Томпсон создавали Go, они просто взяли код этого тулчейна и адаптировали. Это дало мгновенно работающий компилятор — а потом уже много лет выпрямляли и модернизировали.

Уникальные преимущества своего линкера:

• Кросс-компиляция без тулчейна. GOOS=linux GOARCH=arm64 go build на macOS — готов бинарник для Linux ARM64. Нет нужды в кросс-компиляторах, sysroot, glibc-headers-for-target. Go linker сам знает формат ELF, сам генерирует правильные структуры.
• Go-специфичные оптимизации. DCE на уровне отдельных символов (не функций, не файлов). Собственная генерация .gopclntab — таблицы для стектрейсов, рефлексии, сборщика мусора. Собственный DWARF-генератор.
• Полная статика по умолчанию. CGO_ENABLED=0 go build — и получаете один файл, работающий на пустом FROM scratch контейнере Docker. Это один из ключевых факторов успеха Go в облачной эпохе.
• Встроенная поддержка инъекции переменных. go build -ldflags="-X main.version=$(git rev-parse HEAD) -X main.buildTime=$(date -u +%Y-%m-%dT%H:%M:%SZ)" — и в бинарник вошиты версия и время сборки. Без костылей с conf-файлами.
• Воспроизводимые сборки. -trimpath убирает абсолютные пути, сборка побайтно идентична при одинаковом исходнике.
• Уменьшение размера. -ldflags="-s -w": -s убирает таблицу символов, -w — DWARF-инфу. Бинарник уменьшается на 20-30%.
• Плагины. go build -buildmode=plugin — собирает .so-файлы, которые можно загрузить в рантайме через plugin.Open. Работает только на Linux и macOS; на Windows плагины Go до сих пор не поддерживают.

Обратная сторона — скорость и качество кода. Линкер Go медленнее mold и lld. На монорепо Uber с десятками тысяч Go-пакетов линкер съедал гигабайты RAM и тратил минуты. Остин Клементс из Google написал в 2019 году развёрнутый дизайн-док о переписывании — в 2020-2021 годах линкер Go стал быстрее и экономнее по памяти в несколько раз, но до mold всё равно далеко. Плюс — Go не делает LTO в классическом смысле; оптимизации компилятора остаются внутри пакетов. На скорости runtime это сказывается против Rust/C++.

Если CGO_ENABLED=1 (Go вызывает C-код через cgo), Go переключается в режим внешнего линкера: собирает весь Go-код в один .o, затем вызывает gcc/clang для финальной линковки. См. link_demo.go.

Zig: линкер + кросс-компилятор + libc всех цветов

Zig пошёл дальше Go. Он не просто имеет свой линкер, он включает полноценный кросс-тулчейн прямо в одном бинарнике zig:

• Встроенный линкер на основе LLD (ELF, Mach-O, PE/COFF, WASM).
• Заголовочные файлы и исходники libc для 40+ платформ — musl, glibc (различных версий), MinGW, Bionic (Android), mimicks macOS libSystem. Всё внутри дистрибутива.
• zig cc — drop-in замена для gcc/clang с кросс-компиляцией: zig cc -target x86_64-linux-musl hello.c, zig cc -target aarch64-macos -isysroot ....

Это такой сдвиг парадигмы, что многие проекты на Rust (не Zig!) ставят zig cc в качестве линкера через cargo-zigbuild — именно ради кросс-компиляции без мучений с sysroot и glibc-versioning. Vagrant, разработчики CLI-инструментов, инди-игры — используют связку Rust + zig cc для выпуска бинарников под все платформы с одного ноутбука.

@cImport() — ещё одна вещь, меняющая подход к FFI. Zig парсит .h-файлы во время компиляции и делает C-функции напрямую доступными в Zig. Не как в Rust, где нужен bindgen, генерирующий биндинги. Не как в Go, где cgo требует отдельной //#include магии. Zig читает .h и понимает его. См. link_demo.zig.

Инкрементальная компиляция — одна из ключевых долгосрочных целей Zig. Линкер проектируется так, чтобы перелинковывать только изменившиеся участки. На момент Zig 0.16 (2026 год) эта работа ещё не завершена полностью, но направление взято серьёзно.

Rust: гибкость и арбитраж

Rust по умолчанию использует системный линкер: GNU ld на Linux, Apple ld на macOS, link.exe (или lld-link) на Windows. Но любой шаг в сторону — и Cargo позволяет переопределить всё через .cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=mold"]

[target.aarch64-apple-darwin]
rustflags = ["-C", "link-arg=-fuse-ld=lld"]

[target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"

Переход с GNU ld на mold на крупных Rust-проектах (например, rust-analyzer, bevy, сам компилятор Rust) превращает минуты линковки в секунды. Это то изменение конфига, которое окупает себя в первые же часы после внедрения.

Типы крейтов Rust — отдельная тема. Cargo умеет собирать:

• bin — обычный исполняемый файл.
• lib / rlib — Rust-архив, линкуется только другими Rust-крейтами.
• staticlib — архив .a с C ABI, для статической линковки с C.
• cdylib — .so/.dll/.dylib с C ABI, для динамической линковки с C.
• dylib — .so с Rust ABI (не стабилизировано, используется внутри rustc).
• proc-macro — macro-крейт.

Для FFI критичны staticlib и cdylib. Плюс атрибуты:

#[no_mangle]
pub extern "C" fn my_add(a: i32, b: i32) -> i32 {
    a + b
}

#[link(name = "ssl", kind = "static")]
extern "C" {
    fn SSL_library_init() -> i32;
}

Для полной статики — target x86_64-unknown-linux-musl: линковка с musl вместо glibc, результат как у Go, один автономный файл без symbol versioning и других glibc-специфичных страданий. См. link_demo.rs.

Nim: высокоуровневый синтаксис с честной нативной линковкой через C

А теперь кое-что необычное. Nim не имеет собственного бэкенда. Он транслирует свой код в C (по умолчанию), C++ или Objective-C, и дальше эстафету принимает обычный C-компилятор и обычный системный линкер. Если у вас установлены gcc и mold, Nim будет использовать mold. Если вы на macOS — получите быстрый Apple ld-prime. На Windows — MSVC или MinGW по выбору.

Это даёт Nim комбинацию свойств, которой нет у других «высокоуровневых» языков:

1. FFI без биндингов вообще. Прагма {.importc.} объявляет символ внешним. {.header.} включает .h прямо в сгенерированный C-код. Никаких bindgen, никакой генерации врапперов, никаких отдельных шагов:

proc strlen(s: cstring): csize_t {.importc: "strlen", header: "<string.h>".}
echo strlen("hello, linker".cstring)  # 13

Хотите использовать SQLite? import sqlite3 или напрямую объявить пару прагм — и вы вызываете C-библиотеку как родные Nim-функции. Работает настолько нативно, что стирается граница между «C-код» и «Nim-код».

2. Экспорт в линкер под нужным именем. {.exportc.} выставляет Nim-функцию как видимый C-символ без name mangling:

proc nimAdd(a, b: cint): cint {.exportc: "nim_add", cdecl.} =
  a + b

nm покажет: T nim_add. Без всякого _ZN3...E — чистый C-символ, который может вызвать кто угодно. Это фундамент для того, чтобы писать Python-расширения, Node.js-модули или Nintendo Switch игры на Nim.

3. Динамическая линковка на лету. Прагма {.dynlib.} — эквивалент dlopen/LoadLibrary, символ резолвится в момент первого вызова:

when defined(linux):   const libc = "libc.so.6"
elif defined(macosx):  const libc = "libSystem.dylib"
proc getpid(): cint {.importc, dynlib: libc.}

echo "pid = ", getpid()

4. Встраивание чужого C-кода. Прагма {.compile: "vendor/foo.c".} добавляет C-файл прямо в сборку; {.emit: """ ... """.} позволяет встроить C-код буквально в Nim-файл. Граница между Nim и C — чисто синтаксическая, линкер видит один большой C-проект.

5. Агрессивный dead code elimination. Nim при -d:release не тащит в бинарник всё, что вы импортировали — только реально используемые процедуры. Результат: hello world с полной стандартной библиотекой на macOS arm64:

6. Сборщик мусора на выбор — и каждый меняет рантайм.

• --mm:orc (дефолт с 2022) — ARC + цикл-детектор. Детерминированное освобождение памяти, без stop-the-world пауз.
• --mm:arc — чистый ARC без цикл-детектора. Максимальная скорость, если вы сами следите за циклическими ссылками.
• --mm:none — вообще никакого GC. Для embedded, ядер ОС, real-time систем.
• --mm:boehm — классический boehm-gc для совместимости с C-библиотеками.

Выбор --mm меняет то, какой рантайм линкуется в бинарник. С --mm:none получается нативный код уровня C с возможностями Nim — циклические операции с памятью придётся делать вручную.

7. Полная статика через musl. Как и Rust с musl-target, одной строкой:

nim c -d:release --cc:musl-gcc --passC:-static --passL:-static app.nim

Результат — один ELF-файл, запускающийся на любом Linux без зависимостей. Nim собирают так для Nintendo Switch, embedded-устройств, CLI-утилит, распространяемых как один файл.

Вся живая демонстрация — в link_demo.nim. Компилируется и запускается одной командой: nim c -r link_demo.nim.

Часть 11. Практические рекомендации

Для ежедневной разработки

• Rust + mold на Linux. .cargo/config.toml из примера выше. На средних проектах — сотни миллисекунд вместо секунд. На крупных (rust-analyzer, bevy) — минуты превращаются в секунды. Установка:cargo install --locked cargo-binstall cargo binstall mold # или apt install mold / brew install mold
• Rust + sold на macOS. sold (mold для Mach-O) даёт похожий эффект. Или lld через Homebrew.
• Инкрементальная компиляция. Rust и Nim имеют её по умолчанию. Go — частично. Zig — работа в процессе.
• sccache — кеширование компиляции между сессиями. Не ускоряет линковку, но ускоряет всё до неё.

Для продакшн-сборок

• Rust. Thin LTO + strip + codegen-units = 1. Примерно 10-15% ускорения с 2-3-кратным увеличением времени сборки. Для критичных по скорости проектов — добавить Fat LTO и PGO.
• Go. -ldflags="-s -w -X main.version=$(git describe --tags)". Плюс -trimpath для воспроизводимых сборок.
• Zig. По умолчанию zig build -Doptimize=ReleaseFast уже делает достаточно. Для минимального размера — ReleaseSmall.
• Nim. nim c -d:release --opt:speed --passL:-s или --opt:size в зависимости от целей.

Для Docker-контейнеров

• Go. CGO_ENABLED=0 GOOS=linux go build -o app ., затем FROM scratch или FROM gcr.io/distroless/static. Финальный образ — единицы мегабайт.
• Rust. Target x86_64-unknown-linux-musl, затем FROM scratch или FROM alpine. Gotcha: крейты с openssl-sys по умолчанию требуют system openssl; используйте rustls или feature openssl/vendored.
• Nim. nim c -d:release --cc:musl-gcc --passL:-static на Linux с установленным musl-gcc.
• Zig. zig build-exe -target x86_64-linux-musl main.zig -Doptimize=ReleaseSafe.

Для кросс-компиляции

• zig cc как линкер для всего. Rust через cargo-zigbuild, Go через CC="zig cc -target x86_64-linux-musl" CGO_ENABLED=1 go build. Один ноутбук собирает под все платформы без настройки тулчейна.
• Docker с buildx. QEMU-based кросс-сборка, медленнее, но без настройки окружения.

Для отладки и анализа

Инструменты, которые стоит иметь в арсенале:

• nm — список символов. nm ./bin | grep ' T ' — все экспортированные функции.
• objdump -d — дизассемблер. objdump -d ./bin | less — смотрим машинный код.
• readelf -a — всё про ELF-файл: секции, сегменты, символы, релокации, динамическая секция.
• otool (macOS) — аналог для Mach-O: otool -L ./bin покажет зависимости.
• ldd (Linux) — какие .so подтянет программа при запуске. Осторожно: ldd фактически запускает программу, не используйте на недоверенных бинарниках.
• checksec — проверка защитных механизмов (RELRO, stack canaries, NX, PIE).
• bloaty от Google — самый удобный анализатор «почему мой бинарник такой большой». Разделяет по секциям, по C++ namespace, по Rust crate.
• cargo bloat — аналог для Rust, выводит топ самых тяжёлых функций и крейтов.
• twiggy — bloaty для WASM.
• perf — Linux sampling profiler, для PGO и BOLT-профилей.

Как писать код, дружелюбный к линкеру

• -fvisibility=hidden в C/C++ — скрывайте всё по умолчанию, экспортируйте явно. Меньше символов, быстрее линковка, меньше attack surface для DLL hijacking.
• В Rust — pub(crate) по умолчанию, pub только для API.
• В Nim — без * функция не экспортируется из модуля. Это по умолчанию; код у вас дружелюбен к линкеру.
• В Go — маленькая буква в начале = приватный. Опять по умолчанию.
• Для больших C/C++ проектов — -ffunction-sections -fdata-sections -Wl,--gc-sections. 10-30% уменьшения размера.

Эпилог

Линкер — это невидимый диктатор всей индустрии. От него зависит почти всё, что вам важно:

• Автономен ли ваш бинарник или требует набор библиотек.
• Сколько секунд уходит на каждое «собрать и запустить».
• Возможна ли кросс-компиляция без настройки тулчейна.
• Работает ли Docker-образ размером 5 МБ вместо 800 МБ.
• Как быстро стартует программа после двойного клика.
• Насколько защищён бинарник от ROP-атак и подмены GOT.
• Запустится ли ваша программа, собранная сегодня, через двадцать лет.

Go, Zig, Rust и Nim сделали разные архитектурные выборы в этой точке. Go — полностью свой линкер ради кросс-компиляции и статики. Zig — LLD плюс встроенный тулчейн на все случаи жизни. Rust — гибкий выбор системного линкера с мощной системой типов крейтов. Nim — честное партнёрство с C-инфраструктурой через importc/exportc/dynlib. Каждый выбор отражает глубинную философию языка.

А параллельно тихо продолжается гонка: Руи Уэяма в одиночку сделал mold и сдвинул планку в 25 раз. Дэвид Латтимор в Meta пишет Wild и пытается сделать то же самое с инкрементальной линковкой. Apple втихую переписывает ld в Xcode. BOLT от Facebook выжимает дополнительные 10% скорости у уже собранных бинарников. WebAssembly строит совсем другую модель компонентов.

За каждой строчкой «Linking…» в статус-баре вашей IDE — семьдесят лет инженерной эволюции, начавшейся в Кембридже в 1949 году с перфоленты и двадцатилетнего аспиранта по имени Дэвид Уилер.

Следующий раз, когда будете жаловаться на медленную сборку — вспомните, что именно линкер, а не компилятор, скорее всего, этому виной. И знайте: есть mold.

Примеры кода

• link_demo.nim — FFI через {.importc.}, экспорт через {.exportc.}, динамическая линковка {.dynlib.}, dead code elimination, выбор GC.
• link_demo.rs — name mangling, LTO, настройка линкера через .cargo/config.toml, musl-target для полной статики.
• link_demo.go — CGO-переключатель, статическая линковка по умолчанию, внутреннее устройство Go-линкера.
• link_demo.zig — кросс-компиляция без тулчейна, zig cc, @cImport() для прямого импорта C-заголовков.

Источники

• Linkers and Loaders (John R. Levine, 1999) — классическая книга, до сих пор лучший учебник по теме.
• How to Write Shared Libraries (Ulrich Drepper, 2011) — техническая глубина про PLT, GOT, lazy binding и RELRO от одного из мейнтейнеров glibc.
• mold: A Modern Linker (Rui Ueyama) — исходники и дизайн-документы mold.
• LLD — The LLVM Linker — документация LLD.
• Building a Better Go Linker (Austin Clements, 2019) — план переработки линкера Go.
• Fixing Go’s Linker (Uber Engineering) — как Uber боролся с медленной линковкой на своей монорепо.
• Understanding the Go Compiler: The Linker — устройство линкера Go изнутри.
• Zig Build System — документация Zig.
• Nim Manual: Foreign Function Interface — importc/exportc/dynlib в Nim.
• DLL Hell (Wikipedia) — история проблемы.
• Wild Linker — экспериментальный инкрементальный линкер на Rust.
• lld: A Fast, Simple and Portable Linker (Rui Ueyama, LLVM Dev Meeting 2017) — слайды о создании LLD.
• ThinLTO: Scalable and Incremental LTO — документация Thin LTO.
• BOLT: A Practical Binary Optimizer for Data Centers and Beyond (Panchenko et al., 2019) — научная статья про BOLT.
• David Wheeler and the Birth of Subroutines — история изобретения подпрограммы и линковки.
• The 101 of ELF Binaries on Linux — практическое введение в ELF.
• WebAssembly Component Model — будущее модульности в WASM.

Представьте: канун Нового 2017 года. Инфраструктура Cloudflare обслуживает миллионы DNS-запросов в секунду — миллиарды людей не подозревают, что где-то в стоечных залах по всему миру в этот момент начинается маленькая катастрофа.

Ровно в полночь по UTC официальные хранители мирового времени добавили к нему ещё одну секунду. Лишнюю. Поверх обычных 86 400. В этот момент системные часы на серверах Cloudflare сделали шаг назад — и одна строчка кода на Go не смогла это пережить.

Строчка вычитала два вызова time.Now(), чтобы узнать длительность интервала. Длительность внезапно оказалась отрицательной. Отрицательное число попало в rand.Int63n(), которая умеет работать только с положительными значениями. DNS-резолвер запаниковал и упал.

Инцидент затронул около 0,2 % DNS-запросов в 102 дата-центрах и длился почти семь часов. Исправление в коде заняло один символ — замену == 0 на <= 0. Но чтобы этот символ появился на своём месте, команде пришлось признать неудобную истину: время — не число. За кажущейся простотой Date.now() скрываются часовые пояса, меняющиеся по политическим решениям, секунды, которые длиннее других секунд, дни, которых не было, и часы, которые идут назад.

Эта статья — экскурсия по подземельям этой абстракции. С историей, примерами кода на четырёх языках и парой предупреждений на будущее.

Как человечество училось измерять время

До середины XIX века у каждого города были свои часы. Ярославль жил по ярославскому полудню, Томск — по томскому. Всё изменили железные дороги. Без единого расписания поезда сталкивались — буквально, с лязгом металла и человеческими жертвами. Нужно было договариваться.

В 1884 году в Вашингтоне прошла Международная меридианная конференция. Она назначила Гринвичский меридиан нулевым, разделила Землю на часовые пояса и впервые заставила всё цивилизованное человечество согласиться хотя бы в одном: который сейчас час.

В 1967 году физики снова всё переиграли: секунду определили не как долю солнечных суток, а как 9 192 631 770 колебаний атома цезия-133. Атомные часы точнее, чем вращение планеты. И тут выяснилось страшное: Земля — не идеальный хронометр.

Наша планета замедляется из-за приливного трения Луны, ускоряется, когда жидкое ядро перераспределяет массу, и плывёт по времени в свою сторону. Астрономическое время (UT1) и атомное (TAI) постепенно расходятся. Атомная секунда стабильна, а вот секунда «настоящая» — нет.

В 1972 году придумали компромисс: UTC (Coordinated Universal Time) и механизм високосных секунд (leap seconds). Когда UT1 начинает отставать от UTC почти на одну секунду, в UTC добавляется дополнительная — чтобы не терять связь с солнечным днём. С 1972 года таких секунд было добавлено 27, все со знаком плюс. Последняя — 31 декабря 2016 года. Сегодня UTC отстаёт от TAI на 37 секунд. И это отставание — прямое наследство кривизны небесной механики.

Високосные секунды: заплатка, которую решили отменить

Механизм выглядит безобидно: одна лишняя секунда раз в пару лет, кому это может помешать? Но оказалось, что всем.

В момент вставки минута длится не 60 секунд, а 61: после 23:59:59 идёт 23:59:60, а только потом 00:00:00. Большинство программ никогда не видели «60»-ю секунду. Они её и не ждали.

30 июня 2012 года баг в ядре Linux заставил потоки крутиться в бесконечном цикле, выжигая процессор на 100 %. Упали Reddit (полностью), Qantas Airlines (отказ системы бронирования — пассажиры застряли в аэропортах), Mozilla, LinkedIn, Yelp, FourSquare. Cloudflare в 2017 году стал продолжением той же истории, просто на другом языке программирования и в другом дата-центре.

В ноябре 2022 года 27-я Генеральная конференция по мерам и весам (CGPM) приняла историческое решение: отменить високосные секунды к 2035 году (возможно — раньше). Допустимую разницу между UT1 и UTC увеличат, позволят ей накапливаться десятилетиями. Какой именно станет новая «допустимая» величина — решит 28-я CGPM в 2026 году. Возможно, минута. Возможно, больше.

Крупные облачные провайдеры ждать не стали. С 2008 года Google использует так называемый leap smearing — «размазывание» високосной секунды на 24 часа: чуть замедляет или ускоряет все свои часы, и момент вставки проходит незаметно. Amazon и Meta применяют тот же приём. Но у этой хитрости есть побочный эффект: часы Google и часы биржи NYSE расходятся на доли секунды — что при высокочастотной торговле, где миллисекунда решает судьбу миллиона долларов, может иметь последствия.

Климат и секунда, которой ещё не было

В марте 2024 года в журнале Nature появилась статья Дункана Агню из Института океанографии Скриппса с выводом, которого никто не ожидал. Таяние ледников Гренландии и Антарктиды перераспределяет массу планеты: вода стекает от полюсов к экватору, и Земля, как фигурист, разводящий руки, начинает вращаться медленнее.

Следствие: без климатических изменений первую в истории отрицательную високосную секунду пришлось бы вставлять уже к 2026 году. Отрицательную — значит, пропустить одну секунду, пройти от 23:59:58 сразу к 00:00:00. Таяние льдов отсрочило этот момент примерно до 2029-го.

Отрицательную високосную секунду никогда не тестировали. Meta предупредила, что это может оказать «разрушительное влияние» на цифровую инфраструктуру просто потому, что никто не знает, как поведут себя триллионы строк кода, написанного в расчёте на то, что время всегда идёт вперёд. Отличный аргумент, чтобы наконец похоронить всю систему.

День, которого не было

29 декабря 2011 года, четверг, в Самоа завершился как обычно. Следующим днём стала суббота, 31 декабря. Пятница, 30 декабря, в Самоа не существовала.

Причина — экономическая. Главные торговые партнёры островного государства сдвинулись с США в сторону Австралии и Новой Зеландии. А Самоа оставалась на американской стороне линии перемены дат (UTC-11) и теряла два рабочих дня в неделю: когда в Сиднее понедельник, в Апиа ещё воскресенье. Перепрыгнув на UTC+13, страна синхронизировалась с партнёрами и стала одной из первых на планете встречать Новый год. Американское Самоа — всего в ста километрах — осталось на UTC-11. Разница между соседними островами составила 25 часов.

Тем, у кого на несуществующую пятницу была назначена смена, всё равно выплатили зарплату как за полный рабочий день. Банки специально оговорили: проценты за пропущенный день никто не начислит и не спишет.

И это был не первый такой прыжок. 4 июля 1892 года Самоа перепрыгнула в обратную сторону, чтобы синхронизироваться с тогдашним партнёром — США. В тот раз 4 июля праздновали дважды. В 1844 году Филиппины (тогда испанская колония) пропустили 31 декабря, перейдя с американского календарного дня на азиатский. В 1995 году Кирибати сдвинула линию перемены дат и создала пояс UTC+14 — самый крайний в мире.

Следствие, о котором редко думают: в любой момент на Земле одновременно существуют три разных календарных дня. Два часа в сутки — ровно так. Подумайте об этом, когда в следующий раз будете писать new Date().toDateString().

38, а не 24

Распространённое заблуждение: на Земле 24 часовых пояса. На самом деле — примерно 38, от UTC-12 до UTC+14. И не все смещения — целые часы. Индия живёт по UTC+5:30, Непал — по UTC+5:45, острова Чатем в Новой Зеландии — по UTC+12:45. Последнее означает, что перевод встречи «на 15 минут вперёд» в Чатеме может случайно прыгнуть через границу часового пояса.

Часовые пояса меняются постоянно. Это политика, а не физика. Вот беглый взгляд на последние годы из базы IANA (tzdata):

База IANA обновляется несколько раз в год. Если ваше приложение работает с часовыми поясами и вы не обновляете tzdata — вы прямо сейчас показываете неправильное время хотя бы одной категории пользователей. Прямо сейчас, пока вы читаете этот абзац.

Летнее время: часы-призраки и часы-двойники

При переходе на летнее время весной часы перескакивают с 1:59 на 3:00. Час с 2:00 до 3:00 не существует — любое время в этом промежутке невалидно. Осенью часы возвращаются назад, и час с 1:00 до 2:00 повторяется дважды — одно и то же «1:30» становится неоднозначным: до перевода или после?

Звучит как забавный курьёз. А вот истории, которые реальны:

• В больницах медсёстры знают: при осеннем переводе часов записи жизненных показателей за «первый» час с 1:00 до 2:00 могут быть удалены информационной системой, когда часы вернутся к 1:00 и начнут писать поверх. Некоторые клиники на время перехода переключаются на бумажные журналы;
• 9 августа 2022 года правительство Чили объявило, что летнее время начнётся 10 сентября вместо 4 сентября — с уведомлением за месяц. Microsoft Teams и Outlook сдвинули встречи на час не туда, аутентификация Kerberos сломалась из-за несоответствия временных меток;
• В 2005 году США расширили DST на четыре недели. Затраты на патчи и тестирование оценили в 350 миллионов долларов. Такой оказалась стоимость одной строчки в законе.

Два типа часов, которые все путают

Операционная система даёт программисту два совершенно разных механизма измерения времени. Смешение их — источник большинства таймерных багов на свете.

Wall clock (часы реального мира, CLOCK_REALTIME) — показывают текущую дату и время. Синхронизируются через NTP, могут быть переведены вручную, переживают високосные секунды и DST. Могут прыгать вперёд и назад в любой момент.

Monotonic clock (монотонные часы, CLOCK_MONOTONIC) — считают наносекунды с некоторого произвольного момента (обычно — с загрузки системы). Никогда не идут назад. Не привязаны к реальной дате. Бессмысленны после перезагрузки или между разными процессами — это просто счётчик, свой для каждой живой системы.

Разница между этими двумя механизмами — не вопрос эстетики, а ответ на два разных вопроса. Wall clock отвечает на «когда это случилось?» — в такую-то дату, в таком-то часовом поясе. Monotonic — на «сколько прошло между двумя точками?». Одно и то же число не может быть одновременно ответом на оба: момент можно подкрутить через NTP, длительность — нет. Отсюда и правило, за нарушение которого платят production-инциденты:

• измерение длительности (латентность, таймауты, бенчмарки) — монотонные часы;
• запись момента события (логи, временные метки, даты файлов) — wall clock.

Именно это правило Cloudflare и нарушила в 2017 году — не по глупости, а из-за языка. Go до версии 1.9 просто не предоставлял монотонных часов: time.Now() возвращал только wall clock, больше взять было негде. После инцидента Расс Кокс предложил и реализовал встраивание монотонного значения прямо в тип time.Time — и начиная с Go 1.9 каждый вызов time.Now() запоминает оба значения одновременно.

И вот тут становится интересно. Потому что теоретическое знание «для длительности нужны монотонные часы» не спасает никого. Спасает стандартная библиотека, в которой сделать неправильно либо трудно, либо вообще невозможно. Cloudflare научила этому весь мир на своих серверах — и языки ответили на урок по-разному.

Четыре языка, четыре философии

Возьмём одну и ту же небольшую задачу — измерить длительность вычисления, записать момент события, поспать миллисекунду, разобрать Unix timestamp — и посмотрим, как её решают четыре языка с четырьмя разными представлениями о том, что значит «удобно».

Исходники целиком: Rust · Go · Zig · Nim.

Rust: два типа — и точка

Rust подошёл к проблеме радикально: просто сделал монотонные и реальные часы несовместимыми типами. Компилятор не даст их перепутать.

use std::time::{Instant, SystemTime};

// Монотонные часы — для измерения длительности
let start = Instant::now();
// ... работа ...
let elapsed = start.elapsed(); // Duration, всегда >= 0

// Wall clock — для записи момента
let now = SystemTime::now();
let since_epoch = now.duration_since(SystemTime::UNIX_EPOCH); // Result!

Instant::elapsed() возвращает Duration, гарантированно неотрицательную. SystemTime::elapsed() возвращает Result<Duration, SystemTimeError> — компилятор заставляет обработать случай, когда часы пошли назад. Даже если программист этого не хочет. Особенно если не хочет.

Instant при этом нельзя сериализовать: монотонное время не имеет смысла за пределами процесса. Встроенного DateTime в std нет — для календарных операций используют крейты chrono или time.

Go: один тип, два механизма внутри

Go пошёл другим путём: оставил единственный тип time.Time, но спрятал внутри него сразу оба часовых механизма.

start := time.Now() // содержит wall clock + monotonic reading
// ... работа ...
elapsed := time.Since(start) // использует monotonic, игнорирует wall

При вычислении разницы (Sub, Since, Until) Go автоматически берёт монотонное значение, если оно есть у обоих операндов. При сериализации (MarshalJSON, Format) монотонное значение отбрасывается. То же при календарных операциях (AddDate, Round).

Опрос реальных проектов показал: около 30 % вызовов time.Now() в коде на Go измеряют длительность. Дизайн Go делает все эти вызовы корректными автоматически, без изменения публичного API.

У этой элегантности есть ловушки. time.Parse() возвращает Time без монотонного значения — если потом вычислить time.Since(parsedTime), Go откатится к wall clock, и результат может оказаться отрицательным. Ещё одна мина: == и Equal() для time.Time делают разные вещи:

t1 := time.Date(2025, 1, 1, 0, 0, 0, 0, time.UTC)
t2 := time.Date(2025, 1, 1, 0, 0, 0, 0, london) // Europe/London
t1 == t2     // false — разные Location в структуре
t1.Equal(t2) // true  — одно и то же мгновение

И, наконец, легендарная дата-образец Go. Вместо YYYY-MM-DD HH:mm:ss используется магическое Mon Jan 2 15:04:05 MST 2006, в котором все элементы — последовательные числа: 01/02 03:04:05 ‘06 −0700. Элегантно и совершенно непривычно.

Zig: прозрачность и контроль

Несколько дней назад, 5 апреля 2026 года, вышла Zig 0.16.0 — с серьёзно перекроенной стандартной библиотекой. Теперь всё, что связано с вводом-выводом и временем, проходит через новый интерфейс std.Io, который передаётся в main первым параметром. Прежний std.time.Timer, std.time.sleep и std.fs.File.stdout() исчезли.

const std = @import("std");

pub fn main(init: std.process.Init) !void {
    const io = init.io;

    // Монотонные часы (CLOCK_MONOTONIC)
    const start = std.Io.Clock.Timestamp.now(io, .awake);
    // ... работа ...
    const elapsed = start.untilNow(io); // Duration, >= 0

    // Wall clock (Unix epoch)
    const wall = std.Io.Clock.Timestamp.now(io, .real);
    const seconds = wall.raw.toSeconds();    // i64
    const nanos   = wall.raw.toNanoseconds(); // i96

    // Sleep — возвращает Cancelable!void
    try std.Io.sleep(io, std.Io.Duration.fromMilliseconds(1), .awake);
}

В Zig часы — это набор именованных источников: .awake (монотонный, не тикает во время сна системы), .boot (монотонный, тикает всегда), .real (wall clock), .cpu_process, .cpu_thread. Встроенного DateTime нет, но std.time.epoch.EpochSeconds позволяет разложить Unix timestamp на год, месяц, день и секунды. Часовые пояса — только через внешние библиотеки.

Плюс такого подхода — полная прозрачность: никакой магии, понятно, какой источник часов используется. Минус — весь этот контроль лежит на программисте.

Nim: DateTime в стандартной библиотеке

Nim — самый «высокоуровневый» из четырёх. Часовые пояса, парсинг, форматирование и календарная арифметика встроены в стандартную библиотеку, а монотонные часы отделены в собственный модуль.

import std/[times, monotimes, os]

# Монотонные часы — для измерения длительности
let start = getMonoTime()
# ... работа ...
let elapsed = getMonoTime() - start  # Duration, >= 0
echo elapsed.inNanoseconds

# Wall clock и календарь
let now = getTime()
echo now.toUnix        # int64 секунд
echo now.utc           # DateTime в UTC
echo now.local         # DateTime в локальной зоне

# Парсинг и часовые пояса
let m = dateTime(2038, mJan, 19, 3, 14, 7, zone = utc())
echo m.format("yyyy-MM-dd HH:mm:ss zzz")

Time в Nim хранится как (seconds: int64, nanosecond: NanosecondRange) — Y2038 не угрожает. DateTime содержит внутри объект Timezone и потому знает, в каком поясе был создан момент. MonoTime из std/monotimes — обёртка над CLOCK_MONOTONIC, не зависит от NTP и никогда не идёт назад.

Главная ловушка тут — та же, что у Go: при желании можно вычесть два Time, полученных в разные моменты через getTime(), и получить странный результат, если часы перед этим подкрутил NTP. Правильный путь — getMonoTime().

Сравнение

Четыре языка — четыре позиции на спектре: от Rust (максимум защиты, минимум удобства из коробки) до Nim (максимум удобства, аккуратность на совести программиста). Go и Zig — между ними, каждый по-своему.

Y2038: 32-битный апокалипсис

19 января 2038 года, 03:14:07 UTC — момент, когда 32-битный знаковый Unix timestamp (int32) переполнится. Число 2 147 483 647 прыгнет в −2 147 483 648, и устройства, живущие в таких часах, внезапно окажутся в декабре 1901 года.

Это не гипотеза. Вот что случалось с 32-битными счётчиками раньше:

• Boeing 787 (2015). Федеральное авиационное управление США выпустило директиву о лётной годности: блоки управления генераторами входили в аварийный режим после 248 дней непрерывной работы. Причина — переполнение счётчика сотых долей секунды в int32 (2³¹/100/86400 ≈ 248 дней). Временное решение: перезагружать самолёт минимум раз в 248 дней;
• Зонд Deep Impact (2013). После успешной миссии по комете Темпеля зонд продолжал работать ещё восемь лет — пока 32-битный счётчик десятых долей секунды не переполнился (~13,5 лет). Связь с Землёй пропала навсегда;
• Microsoft Zune (31 декабря 2008). Тысячи плееров зависли одновременно: прошивка не умела обрабатывать 366-й день високосного года и уходила в бесконечный цикл. Решение от Microsoft звучало издевательски: «подождите до 1 января».

Софт давно отреагировал. В ядре Linux с 2020 года time_t — 64-битный даже на 32-битных архитектурах. Стандартные библиотеки современных языков хранят время с огромным запасом: Rust — секунды в u64, Go — наносекунды в int64 (до 2262 года), Zig — i96 наносекунд, Nim — int64 секунд. Чтобы написать сегодня приложение, которое сломается 19 января 2038, нужно постараться.

Проблема в другом — в железе и прошивках, которые написаны «на двадцать лет вперёд, и чтобы не трогали». 32-битные микроконтроллеры в домашних маршрутизаторах, промышленных контроллерах на заводах, автомобильной электронике и медицинских приборах останутся в строю ещё десятилетия. Их прошивки часто используют 32-битный time_t просто потому, что у CPU нет 64-битной арифметики, а обновления на них давно никто не выпускает. Для этого класса устройств 19 января 2038 года — не абстракция, а вполне конкретная дата, после которой часть из них просто перестанет корректно работать.

И чтобы жизнь не казалась простой: в ноябре 2038 года произойдёт очередной GPS Week Number Rollover для устройств с 10-битным счётчиком недель. Два переполнения в одном году.

Почему sleep(1) не спит ровно секунду

Сама функция sleep() (и её аналоги во всех языках) не гарантирует точную задержку. Она гарантирует не менее запрошенного времени. Операционная система может разбудить процесс позже — если процессор занят, если планировщик решил иначе, если произошло прерывание.

Демонстрация прямо из прогона Zig-примера: запросили 1 миллисекунду, получили 1290 микросекунд. На 29 % больше, и это нормальное поведение.

Для задач, где точность критична — мультимедиа, управление оборудованием, промышленные протоколы, — используют другие механизмы: таймеры высокого разрешения (CLOCK_MONOTONIC + timerfd), real-time планировщики, а в предельных случаях — busy-wait циклы, выжигающие ядро процессора ради нескольких микросекунд точности.

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

В 2012 году Ноа Суссман составил знаменитый список заблуждений — из тех, что все без исключения разделяют, пока не обожгутся. Вот самые цепкие:

• «В сутках 24 часа». Нет. При переходе на летнее время бывают 23- и 25-часовые сутки. При вставке високосной секунды — 86 401 секунда вместо 86 400;
• «В каждых сутках есть полночь». Нет. При весеннем переводе часов полночь может просто не существовать;
• «Часовых поясов — 24». Нет. Как мы уже говорили, их в районе 38, от UTC−12 до UTC+14;
• «Смещения всегда кратны часу». Нет. UTC+5:30, UTC+5:45, UTC+12:45;
• «Разница между двумя часовыми поясами постоянна». Нет. Политики меняют смещения иногда за несколько дней до события;
• «Системные часы всегда идут вперёд». Нет. NTP, високосные секунды и ручная коррекция могут откатить время назад;
• «Длительность системной минуты примерно равна настоящей». Нет. NTP-slewing может растягивать или сжимать частоту, чтобы мягко догонять атомное время.

Если вы удивились хотя бы одному пункту — продолжайте читать.

Что из этого следует

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

1. Используйте монотонные часы для измерения длительности. Instant в Rust, time.Now() + time.Since() в Go, std.Io.Clock.Timestamp.now(io, .awake) в Zig, getMonoTime() в Nim — все они защищают от прыжков wall clock. Если вы вычитаете два SystemTime или два time.Parse()-результата — вы уязвимы;
2. Храните время в UTC. Часовой пояс — свойство отображения, а не хранения. Сохраняйте Unix timestamp или ISO 8601 с явным смещением, а не «локальное время» без контекста;
3. Обновляйте tzdata. Часовые пояса — политическое решение, а не физическая константа. Ливан менял дату перехода на DST трижды за несколько недель в 2023 году. Если ваша база устарела, вы показываете неправильное время;
4. Не доверяйте sleep(). Он гарантирует минимум, а не точность. Для критичных интервалов используйте таймеры ОС;
5. Готовьтесь к 2038 году. Если ваша система хранит время в int32 — у вас есть 12 лет. Для многих встроенных систем этого не хватит.

Время — это не число. Это политика, астрономия, аппаратные причуды и десятки угловых случаев, каждый из которых кто-то уже превратил в продакшен-инцидент. Следующий инцидент, возможно, — ваш.

Источники

• How and why the leap second affected Cloudflare DNS (Cloudflare, 2017) — разбор того самого новогоднего падения
• A global timekeeping problem postponed by global warming (Nature, 2024) — как таяние ледников отсрочило отрицательную секунду
• It’s time to leave the leap second in the past (Meta, 2022) — аргументы Meta против високосных секунд
• Resolution 4 of the 27th CGPM (2022) — официальное решение об отмене високосных секунд к 2035 году
• Falsehoods programmers believe about time (Noah Sussman, 2012) — классический список заблуждений
• Go Proposal: Monotonic Elapsed Time Measurements — как в Go появились монотонные часы
• Rust std::time::Instant — документация монотонных часов Rust
• Rust std::time::SystemTime — документация wall clock в Rust
• Zig 0.16.0 Release Notes — новая подсистема std.Io
• Nim stdlib: times and monotimes — документация модулей работы со временем в Nim
• Year 2038 problem (Wikipedia) — обзор проблемы Y2038
• GPS Week Number Rollover (GPS.gov) — переполнение счётчика GPS-недель
• IANA Time Zone Database — база часовых поясов
• Time in Samoa (Wikipedia) — пропущенная пятница 30 декабря 2011 года
• The hidden costs of Daylight Saving Time (High Earth Orbit) — стоимость DST для софта

Zig — язык, который пытается решить задачу, за которую мало кто берётся всерьёз: сделать системное программирование понятным и предсказуемым. Без скрытых аллокаций, без сборщика мусора, без магии в рантайме. Там, где C оставляет программиста наедине с неопределённым поведением, а C++ прячет сложность за слоями абстракций, Zig старается быть честным: если что-то происходит, это видно в коде.

Язык всё ещё не достиг версии 1.0, поэтому каждый релиз может переворачивать привычные вещи с ног на голову. Версия 0.16.0 — как раз такой случай. Это не косметическое обновление и не набор багфиксов. Здесь перестроено ядро стандартной библиотеки: весь ввод-вывод теперь проходит через единый интерфейс Io, который можно подменять, тестировать и отменять. Появился новый способ инициализации программы — «сочный main». @Type разобран на восемь специализированных билтинов (builtins — встроенные функции компилятора, которые начинаются с @). Компилятор стал строже к unsafe-паттернам, а в тулчейне обновился LLVM и появились новые платформы.

Изменений много, и перечислять каждое — верный способ усыпить читателя. Поэтому ниже — только то, что действительно влияет на повседневную работу с языком: с примерами кода, сравнениями «было — стало» и объяснением, зачем всё это нужно.

«Сочный main»

Раньше типичный main в Zig начинался с ритуальной инициализации: достать аллокатор, разобрать аргументы, подготовить I/O. Теперь всё это приходит одним параметром:

const std = @import("std");

pub fn main(init: std.process.Init) !void {
    const gpa = init.gpa;             // аллокатор общего назначения
    const io = init.io;               // экземпляр Io для всех операций ввода-вывода
    const arena = init.arena.allocator(); // арена для временных данных

    // аргументы командной строки — тоже через init
    const args = try init.minimal.args.toSlice(arena);

    std.log.info("первый аргумент: {s}", .{args[0]});
}

Никакого шаблонного кода для запуска. Аллокатор, I/O и арена готовы к использованию — остаётся писать логику.

Io как интерфейс: главное архитектурное изменение

Это центральная идея релиза: все операции ввода-вывода теперь принимают параметр io. Файлы, сеть, процессы, генерация случайных чисел, примитивы синхронизации — всё проходит через единый интерфейс std.Io.

Зачем это нужно:

• Тестируемость. В тестах используется std.testing.io — не нужно подменять реальный I/O заглушками вручную.
• Сменяемость бэкенда. Один и тот же код работает поверх потоков, io_uring, kqueue или Grand Central Dispatch.
• Отмена операций. Любую I/O-операцию можно отменить через единый механизм.

Бэкенды Io

Для миграции с 0.15.x подходит Io.Threaded — он полнофункционален и хорошо протестирован.

Простой пример: HTTP-запрос

Вот как выглядит HTTP HEAD-запрос с новым интерфейсом. DNS-резолвинг, TCP-соединение и отмена — всё работает через io:

const std = @import("std");
const Io = std.Io;

pub fn main(init: std.process.Init) !void {
    const gpa = init.gpa;
    const io = init.io;
    const args = try init.minimal.args.toSlice(init.arena.allocator());

    // DNS-имя парсится из аргумента командной строки
    const host_name: Io.net.HostName = try .init(args[1]);

    var http_client: std.http.Client = .{ .allocator = gpa, .io = io };
    defer http_client.deinit();

    var request = try http_client.request(.HEAD, .{
        .scheme = "http",
        .host = .{ .percent_encoded = host_name.bytes },
        .port = 80,
        .path = .{ .percent_encoded = "/" },
    }, .{});
    defer request.deinit();

    try request.sendBodiless();

    var redirect_buffer: [1024]u8 = undefined;
    const response = try request.receiveHead(&redirect_buffer);
    std.log.info("статус: {d} {s}", .{ response.head.status, response.head.reason });
}

Future и Group: конкурентность без колбэков

Два ключевых инструмента для параллельного выполнения — Future и Group.

Future — это отложенный результат одной операции. Запускаем функцию асинхронно, а результат получаем позже:

// запускаем открытие файла асинхронно
var task = io.async(Io.Dir.openFile, .{ .cwd(), io, "data.txt", .{} });

// при отмене или ошибке — корректно освобождаем ресурс
defer if (task.cancel(io)) |file| file.close(io) else |_| {};

Group управляет множеством параллельных задач. Вот «сортировка сном» — каждый элемент засыпает на время, пропорциональное своему значению:

const std = @import("std");
const Io = std.Io;

test "sleep sort" {
    const io = std.testing.io; // тестовый Io — без настоящих системных вызовов

    const rng_impl: std.Random.IoSource = .{ .io = io };
    const rng = rng_impl.interface();

    var array: [10]i32 = undefined;
    for (&array) |*elem| elem.* = rng.uintLessThan(u16, 1000);

    var sorted: [10]i32 = undefined;
    var index: std.atomic.Value(usize) = .init(0);

    var group: Io.Group = .init;
    defer group.cancel(io); // отмена всех незавершённых задач при выходе

    // запускаем все задачи параллельно
    for (&array) |elem| group.async(io, sleepAppend, .{ io, &sorted, &index, elem });

    try group.await(io); // дожидаемся завершения всех

    // проверяем, что массив отсортирован
    for (sorted[0 .. sorted.len - 1], sorted[1..]) |a, b| {
        try std.testing.expect(a <= b);
    }
}

fn sleepAppend(io: Io, result: []i32, i_ptr: *std.atomic.Value(usize), elem: i32) !void {
    // спим пропорционально значению элемента
    try io.sleep(.fromMilliseconds(elem), .awake);
    result[i_ptr.fetchAdd(1, .monotonic)] = elem;
}

Отмена операций

Любая I/O-операция может быть отменена — через error.Canceled в наборе ошибок. Три стратегии работы с отменой:

1. Пробросить дальше — просто позволить ошибке всплыть по стеку.
2. Повторно установить отмену — вызвать io.recancel() после локальной обработки.
3. Защитить участок — временно отключить отмену через io.swapCancelProtection().

Новые билтины вместо @Type

@Type был универсальным, но громоздким. Теперь вместо одного обобщённого билтина — восемь специализированных: @Int, @Tuple, @Pointer, @Fn, @Struct, @Union, @Enum и @EnumLiteral.

@Int и @Tuple — самый частый случай

// Было: 0.15.x
const U10 = @Type(.{ .int = .{ .signedness = .unsigned, .bits = 10 } });

// Стало: 0.16.0
const U10 = @Int(.unsigned, 10);

// Было: 0.15.x — 12 строк на объявление кортежа
const MyTuple = @Type(.{ .@"struct" = .{
    .layout = .auto,
    .fields = &.{.{
        .name = "0",
        .type = u32,
        .default_value_ptr = null,
        .is_comptime = false,
        .alignment = @alignOf(u32),
    }, .{
        .name = "1",
        .type = [2]f64,
        .default_value_ptr = null,
        .is_comptime = false,
        .alignment = @alignOf([2]f64),
    }},
    .decls = &.{},
    .is_tuple = true,
} });

// Стало: 0.16.0 — одна строка
const MyTuple = @Tuple(&.{ u32, [2]f64 });

@Struct — генерация структур в comptime

@Struct позволяет создавать структуры с произвольными полями во время компиляции. Это полезно для метапрограммирования — например, генерации обёрток над перечислениями:

const std = @import("std");

// создать структуру, где каждому варианту перечисления соответствует поле
fn EnumFieldMap(comptime E: type, comptime FieldType: type) type {
    return @Struct(
        .auto,                          // layout
        null,                           // backing integer (нет)
        std.meta.fieldNames(E),         // имена полей — из перечисления
        &@splat(FieldType),             // все поля одного типа
        &@splat(.{}),                   // без дополнительных атрибутов
    );
}

@Enum — динамические перечисления

// создаём enum с явным backing-типом и значениями
const Color = @Enum(
    u8,            // backing integer
    .exhaustive,   // исчерпывающий (не допускает неизвестных значений)
    &.{ "red", "green", "blue" },
    &.{ 0, 1, 2 },
);

Что не стало билтином

Для float, array, opaque, optional и error_union отдельные билтины не нужны — используется обычный синтаксис языка. Наборы ошибок (error sets) тоже больше нельзя создавать через рефлексию: объявляйте их явно через error { ... }.

Безопасность на уровне языка

Запрет на возврат адреса локальной переменной

Классическая ошибка, которая в C приводит к use-after-free, теперь ловится на этапе компиляции:

fn foo() *i32 {
    var x: i32 = 1234;
    return &x;
    // ошибка компиляции: returning address of expired local variable 'x'
}

Указатели в packed-структурах запрещены

Указатели внутри packed struct и packed union больше не допускаются — вместо них нужно использовать usize с явным преобразованием через @ptrFromInt/@intFromPtr. Это исключает неопределённое поведение при работе с битовыми представлениями.

packed union: все поля одного размера

Раньше можно было объявить packed union с полями разного размера — неиспользуемые биты просто игнорировались. Теперь это ошибка:

// Ошибка компиляции в 0.16.0: поля разного размера
const U = packed union {
    x: u8,
    y: u16,
};

// Правильно: явный backing-тип и выравнивание
const U = packed union(u16) {
    x: packed struct(u16) {
        data: u8,
        padding: u8 = 0,
    },
    y: u16,
};

Явные backing-типы в extern-контексте

Перечисления и packed-типы с неявным backing-типом больше нельзя использовать в extern-контексте. Компилятор требует указать тип явно:

// Ошибка в 0.16.0
const Status = enum { ok, err };
export var s: Status = .ok;

// Правильно
const Status = enum(u8) { ok, err };
export var s: Status = .ok;

Запрет на runtime-индексацию векторов

SIMD-векторы больше нельзя индексировать переменной времени выполнения. Если нужен поэлементный доступ, приведите вектор к массиву:

// Ошибка в 0.16.0
for (0..vector_len) |i| {
    _ = vector[i]; // runtime index запрещён
}

// Правильно: приводим вектор к массиву
const info = @typeInfo(@TypeOf(vector)).vector;
const array: [info.len]info.child = vector;
for (&array) |elem| {
    _ = elem;
}

Конвертация чисел: меньше рутинного кода

Маленькие целые автоматически приводятся к float

Целочисленные типы до 24 бит включительно теперь неявно приводятся к f32 без потери точности, потому что мантисса f32 вмещает все их значения:

var foo_int: u24 = 123;
var foo_float: f32 = foo_int; // работает без @floatFromInt

var bar_int: u25 = 123;
var bar_float: f32 = @floatFromInt(bar_int); // u25 не помещается — нужна явная конвертация

@floor, @ceil, @round, @trunc конвертируют в целые

Раньше для округления f32 до u8 требовалась цепочка @intFromFloat(@round(value)). Теперь @round (и другие) умеют конвертировать напрямую:

const std = @import("std");

test "round to int" {
    try example(12, 12.34);
    try example(13, 12.50);
}

fn example(expected: u8, value: f32) !void {
    const actual: u8 = @round(value); // float -> int за один шаг
    try std.testing.expectEqual(expected, actual);
}

@intFromFloat для этих случаев помечен как deprecated.

Стандартная библиотека: что ещё нового

Deflate-сжатие на чистом Zig

В стандартной библиотеке появилась реализация deflate-компрессора. Раньше была только декомпрессия. Три режима работы:

• Standard — полноценное сжатие (по умолчанию);
• Raw — хранение без сжатия;
• Huffman — сжатие кодами Хаффмана без поиска совпадений.

Производительность сопоставима с zlib:

Для большинства задач разница в степени сжатия незаметна, а выигрыш в скорости ощутим. И никакой зависимости от C-библиотеки.

ArenaAllocator стал потокобезопасным

std.heap.ArenaAllocator теперь использует атомарные операции вместо мьютекса. В однопоточном режиме скорость не изменилась, а при использовании из нескольких потоков (до ~7) — заметно быстрее, чем старый вариант с ThreadSafeAllocator. Сам ThreadSafeAllocator удалён за ненадобностью.

Новые криптоалгоритмы

Добавлены реализации AES-SIV, AES-GCM-SIV, а также семейство Ascon (Ascon-AEAD, Ascon-Hash, Ascon-CHash). Всё на чистом Zig, без внешних зависимостей.

@cImport уходит в build-систему

@cImport помечен как deprecated. Трансляция C-заголовков теперь выполняется через addTranslateC в build.zig:

// build.zig
const translate_c = b.addTranslateC(.{
    .root_source_file = b.path("src/c.h"),
    .target = target,
    .optimize = optimize,
});
translate_c.linkSystemLibrary("glfw", .{});
translate_c.linkSystemLibrary("epoxy", .{});

const exe = b.addExecutable(.{
    .name = "app",
    .root_module = b.createModule(.{
        .root_source_file = b.path("src/main.zig"),
        .optimize = optimize,
        .target = target,
        .imports = &.{
            .{ .name = "c", .module = translate_c.createModule() },
        },
    }),
});

А в коде вместо @cImport — обычный импорт:

const c = @import("c");

Сами заголовки живут в обычном .h-файле:

// src/c.h
#include <stdio.h>
#include <GLFW/glfw3.h>
#include <epoxy/gl.h>

Преимущества: C-трансляция встроена в граф зависимостей сборки, работает кэширование, а build.zig полностью описывает все внешние зависимости.

Компилятор и тулчейн

LLVM 21

Компилятор обновлён до LLVM 21. Из-за регрессии в LLVM временно отключена векторизация циклов. Её вернут, когда апстрим исправит баг.

Новые платформы второго уровня (тестируются в CI)

К уже поддерживаемым платформам добавлены:

• aarch64-freebsd, aarch64-netbsd;
• x86_64-freebsd, x86_64-netbsd, x86_64-openbsd;
• loongarch64-linux, powerpc64le-linux, s390x-linux.

Появилась базовая поддержка экзотических архитектур: Alpha, KVX, MicroBlaze, OpenRISC, PA-RISC, SuperH. Убрана поддержка Oracle Solaris, IBM AIX и IBM z/OS (illumos остаётся).

Фаззер Smith

Новый AST-фаззер Smith генерирует синтаксически корректные программы на Zig и проверяет, что компилятор не падает. Поддерживается мультипроцессный фаззинг, бесконечный режим и автоматическое сохранение краш-дампов. С помощью Smith уже найдены и исправлены десятки багов.

Пакетный менеджер

Два полезных улучшения:

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

Миграция с 0.15.x: всё в одном месте

Основной паттерн миграции: добавить параметр io к вызовам I/O-функций. Получить io проще всего через «сочный main» (std.process.Init), а в тестах — через std.testing.io.

Файловая система

Примитивы синхронизации

Процессы

Случайные числа

Время

Коды ошибок

Удалено без замены

• std.heap.ThreadSafeAllocator — ArenaAllocator теперь потокобезопасен сам по себе;
• std.Thread.Mutex.Recursive — перепроектируйте код без рекурсивных блокировок;
• std.once — избегайте ленивой инициализации глобального состояния;
• std.SegmentedList — используйте ArrayList или другие контейнеры;
• std.Io.GenericReader, std.Io.AnyReader, std.Io.FixedBufferStream — заменены новым I/O-интерфейсом;
• std.fs.getAppDataDir — без замены;
• Z/W-суффиксные варианты функций файловой системы (realpathZ, openDirAbsoluteZ, deleteDirZ и т. д.) — используйте основные функции из std.Io.Dir.

Итого

Zig 0.16.0 — это прежде всего архитектурный сдвиг. Io-интерфейс пронизывает всю стандартную библиотеку, делая код тестируемым и переносимым между бэкендами. Новые билтины упрощают метапрограммирование, а усиленные проверки компилятора ловят ошибки, которые раньше приводили к UB в рантайме.

Миграция с 0.15.x потребует усилий — API файловой системы, потоков и процессов переехали почти целиком. Но паттерн изменений единообразный: добавить io в параметры и обновить пути импортов. Полный список изменений — в официальных release notes.

Сходил сегодня на УЗИ, и меня «обрадовали» жировым гепатозом и — неожиданно — хроническим панкреатитом. И если против гепатоза никаких возражений нет — вполне закономерно при ИМТ 37, то вот насчёт панкреатита, да ещё и хронического, у меня большие сомнения.

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

Ещё у меня не в порядке почки. Об этом я тоже знал, УЗИ просто подтвердило, что мне нужно обратиться к урологу.

Первое дело при гепатозе и панкреатите — правильная диета и снижение веса до нормы. Так что изучил клинические рекомендации и составил примерное меню, список покупок и рецепты. Ну и принципы питания, куда же без них.

Чтобы не потерять проделанную работу в бесконечном количестве документов и текстов, решил опубликовать это в блоге. Тем более, что это может пригодиться не только мне.

При жировом гепатозе и хроническом панкреатите вне обострения подходит одна и та же базовая схема питания. Ниже — принципы, меню на неделю, список покупок и рецепты.

Важно. Это меню подходит как базовый вариант вне острого приступа. При сильной боли, рвоте, температуре или резком ухудшении после еды необходима очная медицинская помощь, а не домашняя диета.

Принципы питания

Общие для обоих состояний

• 4–5 приёмов пищи в день умеренными порциями.
• Способы готовки: варка, запекание, тушение, на пару.
• Пить воду регулярно в течение дня.
• Если конкретный продукт вызывает боль, тяжесть, тошноту или жидкий стул — временно исключить и обсудить с врачом.

При жировом гепатозе

• Главная цель — постепенное снижение веса, если есть избыток. Снижение массы тела на 7–10 % даёт заметное улучшение состояния печени.
• Полезны овощи, цельные злаки, жирная рыба (источник омега-3), оливковое масло, орехи в умеренном количестве — всё это элементы средиземноморской диеты.
• Для печени особенно вредна фруктоза в больших количествах — ограничивать не только сахар, но и фруктовые соки.
• Кофе без сахара допустим и даже полезен: есть данные о его защитном действии на печень. И это меня очень-очень радует, как большого любителя этого прекрасного напитка.

При хроническом панкреатите вне обострения

• Пожизненная сверхжёсткая обезжиренная диета не нужна всем подряд — жирность рациона подбирается по симптомам.
• При недостаточности ферментов врач может назначить ферментные препараты. Именно они позволяют не урезать жиры до минимума, а питаться нормально.
• Бобовые полезны по составу, но могут вызывать вздутие — вводить постепенно, по переносимости.
• Слишком много клетчатки за раз может снижать эффективность ферментных препаратов. Умеренное количество овощей и круп — нормально; увлекаться отрубями и сырыми салатами в больших объёмах не стоит.
• Важно контролировать уровень жирорастворимых витаминов (A, D, E, K) и при необходимости принимать их дополнительно — обсудить с врачом.

Что есть

Продукты внутри каждой категории взаимозаменяемы: например, курицу можно заменить индейкой или рыбой, гречку — рисом или картофелем, кабачки — брокколи или цветной капустой.

Что исключить

• алкоголь;
• жареное;
• жирное мясо (сало, жирная свинина);
• колбасы, сосиски, копчёности;
• фастфуд (бургеры, пицца);
• сладкая газировка, соки в большом количестве;
• торты, сладкая выпечка как повседневная еда;
• майонез, жирные соусы.

Ориентир по порциям

Меню на неделю

При сильном голоде можно добавить ещё один небольшой перекус: кефир, 100–150 г творога или печёное яблоко.

Список покупок на неделю

Белок

• Куриная грудка — 1,2–1,5 кг.
• Индейка (филе или фарш) — 800 г – 1 кг.
• Нежирная рыба (хек, минтай, треска) — 800 г – 1 кг.
• Лосось или скумбрия — 300–400 г (на 1–2 приёма).
• Яйца — 15 шт.
• Творог 2–5 % — 1,2–1,5 кг.
• Йогурт без сахара — 7 шт. (~150 г каждый) или 1 л.
• Кефир 1 % — 1–1,5 л.

Крупы и гарниры

• Овсяные хлопья — 300–400 г.
• Гречка — 400–500 г.
• Рис — 400–500 г.
• Вермишель — 1 пачка (400 г).
• Картофель — 1,5–2 кг.
• Хлебцы или галеты — 1 пачка.

Овощи

• Кабачки — 1–1,5 кг.
• Морковь — 700 г – 1 кг.
• Цветная капуста — 1 кочан (~500 г) или замороженная.
• Брокколи — 500–700 г.
• Тыква — 500 г – 1 кг (по желанию).
• Свёкла — 500 г (по переносимости).

Фрукты

• Яблоки — 1 кг.
• Бананы — 5–7 шт.
• Груши мягкие — 3–4 шт.

Дополнительно

• Молоко 1–1,5 % — 1 л.
• Оливковое масло — 1 бутылка (250–500 мл).
• Чай, кофе.
• Соль.

Рецепты

1. Овсянка

Ингредиенты: 50 г овсяных хлопьев, 200 мл воды (или 100 мл воды + 100 мл молока 1,5 %), щепотка соли.

Приготовление. Залить жидкостью, варить 5–7 минут, помешивая. По желанию добавить половину банана или 50 г тёртого яблока.

На выходе: ~250 г.

2. Омлет на пару

Ингредиенты: 2 яйца, 40 мл молока 1,5 %, щепотка соли.

Приготовление. Взбить вилкой, вылить в форму. Готовить на пару, в мультиварке, в микроволновке (2–3 минуты) или на сковороде под крышкой на минимальном огне без масла.

3. Куриная грудка в духовке

Ингредиенты: 700–800 г куриной грудки, ½ ч. л. соли, 50 мл воды.

Приготовление. Нарезать грудку на куски толщиной 2–3 см, посолить, выложить в форму, добавить воду, плотно накрыть фольгой. Запекать при 180 °C 25–30 минут.

Хватает на: 2–3 дня. Использовать с любым гарниром и овощами.

4. Тефтели из индейки

Ингредиенты: 500 г фарша индейки, 1 яйцо, 50 г отварного риса (по желанию), ½ ч. л. соли.

Приготовление. Смешать все ингредиенты, сформировать шарики диаметром ~4 см (~15–18 штук), выложить в форму, добавить 50 мл воды, накрыть фольгой. Запекать при 180 °C 25–30 минут.

Порция: 4–5 штук.

5. Рыба запечённая

Ингредиенты: 400–500 г филе (хек, минтай или треска), ¼ ч. л. соли, 30 мл воды.

Приготовление. Выложить филе в форму, посолить, добавить воду, накрыть фольгой. Запекать при 180 °C 20–25 минут. Подавать с картофелем, рисом или овощным пюре.

6. Суп с курицей

Ингредиенты: 300 г куриной грудки, 300 г картофеля (2–3 шт.), 100 г моркови (1 средняя), 50 г вермишели или 40 г риса, 1,5 л воды, ½ ч. л. соли.

Приготовление. Курицу залить водой, довести до кипения, снять пену. Добавить нарезанный картофель и морковь. Варить 15 минут. Добавить вермишель или рис, варить ещё 7–10 минут. Без зажарки.

Хватает на: 2–3 дня.

7. Овощной суп-пюре

Ингредиенты: 200 г кабачка, 150 г моркови (1 крупная), 200 г цветной капусты или брокколи, 200 г картофеля (1–2 шт.), 1 л воды, ½ ч. л. соли.

Приготовление. Всё нарезать, залить водой, варить до мягкости (~20 минут). Измельчить блендером. Если слишком густо — добавить воды от варки.

Хватает на: 2 дня.

8. Рыбный суп

Ингредиенты: 300 г филе белой рыбы, 300 г картофеля (2–3 шт.), 100 г моркови (1 шт.), 1,2 л воды, ½ ч. л. соли.

Приготовление. Картофель и морковь нарезать, залить водой, варить 15 минут. Добавить рыбу кусками, варить ещё 10 минут. Без зажарки.

9. Картофельное пюре

Ингредиенты: 500 г картофеля (4–5 средних клубней), 50–70 мл тёплого молока 1,5 %, щепотка соли. Масло — не более 5 г или без него.

Приготовление. Картофель очистить, отварить до мягкости (~20 минут), слить воду. Размять, добавить тёплое молоко, перемешать до однородности.

10. Творожная запеканка

Ингредиенты: 400 г творога 2–5 %, 1 яйцо, 40 г овсяных хлопьев или манки. Без сахара или с минимумом подсластителя.

Приготовление. Смешать все ингредиенты, выложить в форму (можно застелить пергаментом). Запекать при 180 °C 30–35 минут до золотистой корочки.

На выходе: ~500 г. Порция — 200–250 г.

11. Тушёные кабачки с морковью

Ингредиенты: 400 г кабачков, 100 г моркови (1 шт.), 50 мл воды, щепотка соли.

Приготовление. Кабачки нарезать кубиками, морковь — мелко или на тёрке. Сложить в кастрюлю, добавить воду, тушить под крышкой 15–20 минут до мягкости.

12. Брокколи или цветная капуста на пару

Ингредиенты: 400 г соцветий, щепотка соли.

Приготовление. Разобрать на соцветия, готовить на пару или отварить в небольшом количестве воды 10–12 минут до мягкости.

План готовки на неделю

Чтобы не стоять у плиты каждый день, достаточно двух сессий готовки.

Воскресенье — база на понедельник–среду

Белок:

• запечь 700–800 г куриной грудки (рецепт 3);
• сделать тефтели из 500 г фарша индейки (рецепт 4).

Гарниры:

• сварить кастрюлю гречки (~200 г сухой);
• сварить кастрюлю риса (~200 г сухого);
• отварить картофель (~500 г).

Овощи:

• потушить кабачки с морковью (рецепт 11);
• отварить или приготовить на пару брокколи / цветную капусту (рецепт 12).

Суп:

• сварить суп с курицей на 2–3 дня (рецепт 6).

Завтраки:

• сделать творожную запеканку (рецепт 10);
• держать наготове творог, яйца, овсянку.

Среда — база на четверг–воскресенье

Белок:

• запечь 400–500 г рыбы (рецепт 5);
• запечь 500–700 г курицы или индейки.

Гарниры:

• сварить гречку или рис;
• приготовить картофельное пюре (рецепт 9).

Овощи:

• потушить новую порцию овощей;
• сварить овощной суп-пюре (рецепт 7) или рыбный суп (рецепт 8).

Перекусы — докупить/пополнить:

• творог, йогурт, кефир, бананы, яблоки.

Быстрая сборка из заготовок

Из готовой базы еда собирается за несколько минут:

1. Курица + гречка + тушёные кабачки.
2. Тефтели из индейки + рис + брокколи.
3. Рыба + картофельное пюре + цветная капуста.
4. Суп + хлебцы; творог на перекус.
5. Творожная запеканка + йогурт.

Памятка

Не жарить. Не пить алкоголь. Есть 4–5 раз в день. Белок — в каждый основной приём пищи. Гарнир — умеренно. Сладкое и фастфуд — убрать. При избыточном весе — стремиться к постепенному снижению на 7–10 % от текущей массы тела.

Источники

• NIDDK — Eating, Diet, & Nutrition for NAFLD & NASH
• NIDDK — Eating, Diet, & Nutrition for Pancreatitis
• NIDDK — Treatment for NAFLD & NASH
• EASL–EASD–EASO Clinical Practice Guidelines on MASLD (2024)
• ESPEN Practical Guideline on Nutrition in Chronic Pancreatitis (2023)

Семён Кротов собирал тишину.

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

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

Тишина детской игрушки, потерянной на пустыре — острая, пронзительная. Тишина старых книг в закрывшейся библиотеке — тёплая, чуть пыльная. А тишина между словами «я тебя больше не люблю» — она горькая, как полынь, и режет хуже ножа.

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

Всё изменилось, когда он услышал объявление в метро:

«Внимание! На станции «Тихая» возможна задержка поездов в связи с техническими работами».

Проблема была в том, что станции «Тихая» в московском метро не существовало.

Семён перепроверил схему — между «Сухаревской» и «Проспектом Мира» была только «Цветной бульвар». Спросил у других пассажиров — никто ничего не слышал. Объявление прозвучало только для него.

А через неделю, поздним вечером, поезд действительно остановился в неположенном месте. Двери открылись, и Семён увидел платформу, которой не должно было быть.

Табличка гласила: «Тихая». Станция была пустынной, освещённой тусклыми лампами. И там царила такая тишина, какой Семён не слышал никогда.

Это была тишина до начала времён. Тишина небытия. Абсолютная, кристально чистая, почти болезненная в своём совершенстве.

Семён вышел. Поезд исчез, словно растворился в воздухе.

На станции больше не было никого, кроме пожилого дежурного в старой форме.

— Добро пожаловать в архив, — сказал тот. — Я Николай Семёнович, хранитель. Давно вас ждал, коллекционер.

Оказалось, что станция «Тихая» — это хранилище всей тишины мира. Каждого молчания, каждой паузы, каждого невысказанного слова. Николай Семёнович собирал её уже пятьдесят лет.

— Но зачем? — спросил Семён, бродя по бесконечным залам, где в стеклянных резервуарах хранились различные виды безмолвия.

— А зачем нужны библиотеки? — ответил старик. — Кто-то же должен сохранять то, что люди теряют. Мир становится всё громче. Скоро настоящей тишины не останется вовсе.

В одном зале Семён увидел огромный резервуар с табличкой «Последняя тишина Земли».

— Что это?

— То, что останется, когда люди замолкнут навсегда, — грустно пояснил Николай Семёнович. — Она уже собрана. Из будущего. Время здесь работает не так, как снаружи.

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

— Хотите стать моим помощником? — предложил хранитель. — У вас талант. А мне скоро на пенсию.

— Но как же моя жизнь наверху?

— А какая разница? Здесь у вас будет доступ ко всей тишине мира. Вы сможете изучать её, классифицировать, оберегать от исчезновения.

Семён колебался. Предложение было заманчивым. Но что-то его смущало.

— А вы сами не скучаете по звукам?

Николай Семёнович задумался:

— Знаете, после стольких лет в тишине начинаешь понимать… без звука она теряет смысл. Тишина существует только в противовес шуму. Она определяется тем, чего в ней нет.

— И что вы хотите этим сказать?

— Что, возможно, мы делаем не то. Сохраняем тишину, но убиваем её суть. Коллекционируем безмолвие, но лишаем его жизни.

В этот момент Семён услышал что-то невероятное — из одного резервуара доносился слабый звук. Плач.

— Это что?

— Тишина после похорон, — вздохнул хранитель. — Она… портится. Начинает звучать. Такое иногда случается с самой болезненной тишиной.

Семён подошёл ближе. И понял: тишина плакала, потому что её разлучили с горем, которое её породило. Она была неполной без слёз, которые должны были её заполнить.

— Николай Семёнович, а что, если мы всё делаем неправильно?

— В каком смысле?

— Тишина не должна жить в банках. Она должна жить между звуками. В паузах. В моментах, когда люди замолкают, чтобы услышать своё сердце.

Старик посмотрел на свою коллекцию новыми глазами:

— Вы хотите сказать, что мы… крадём тишину у мира?

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

Они стояли в архиве украденной тишины и понимали масштаб ошибки.

— Что же делать? — прошептал Николай Семёнович.

— Вернуть.

Они открыли все резервуары. Тишина рванула наружу, как вода из прорвавшейся плотины. Тишина снежинок вернулась к зимним вечерам, тишина библиотек — к читальным залам, тишина между ударами сердца — к влюблённым.

Станция начала растворяться.

— А что будет с вами? — крикнул Семён хранителю сквозь нарастающий гул освобождающейся тишины.

— Я тоже вернусь! — улыбнулся тот. — К своей семье, к звукам настоящей жизни!

Семён очнулся в вагоне метро. Пассажиры вокруг шумели, разговаривали по телефонам, смеялись. И между звуками, в паузах их речи, жила правильная тишина. Живая, осмысленная, нужная.

Дома он разобрал свои приборы для ловли безмолвия. Вместо этого стал записывать звуки — смех детей, шум дождя, тихое дыхание спящего города. А тишину оставил там, где она должна быть.

В промежутках между звуками. В секундах раздумий. В мгновениях, когда сердце замирает от красоты.

Иногда в метро он слышал объявления о задержках на несуществующих станциях. Но больше никогда не выходил. Теперь он знал: некоторые коллекции лучше не начинать.

А тишина благодарно окружала его по вечерам, когда он пил чай и слушал, как за окном засыпает мир.

Читал сегодня новостную ленту, и одна публикация заставила меня остановиться. Не потому что была неожиданной, а скорее потому что я увидел, как в законопроект превратили то, что давно витало в воздухе.

«Дзен» претендует на статус Национальной новостной платформы. Виджет с новостями предлагается в обязательном порядке встраивать на главные страницы маркетплейсов, соцсетей и видеосервисов. А какие СМИ попадут в этот виджет — решает правительство.

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

Что именно предлагается

13 апреля «Коммерсантъ» опубликовал материал со ссылкой на внутреннюю презентацию VK. Суть инициативы — поправки в федеральный закон «Об информации», которые могут внести в Госдуму уже в мае 2026 года. Я проверил оригинал и сверил с другими источниками — Хабр, Фонтанка, CNews. Всё сходится. Вот ключевые пункты.

Обязательный виджет. Все поисковые системы, социальные сети, маркетплейсы и видеосервисы должны будут встроить новостной блок «Дзена» на свои главные страницы. В соцсетях и поисковиках — топ-5 новостей. На маркетплейсах и видеоплатформах — кнопка перехода к топ-15 новостям.

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

Государственный отбор СМИ. Какие издания попадут в виджет, определяет правительство РФ. Оно же назначает оператора платформы, причём сразу на пять лет.

Распределение денег. 50 % рекламной выручки идёт площадкам, разместившим виджет. Оставшиеся 50 % — «на поддержку СМИ». Из этой половины 50 % получают конкретные издания, 10 % — некая «ассоциация СМИ». Куда деваются оставшиеся 40 %, в презентации не сказано.

Что VK говорит в своё оправдание

Аргументация VK выглядит так: с 2022 года аудитория российских СМИ упала на 30–70 %. Медиа «критически зависимы от трафика „Дзена"», который обеспечивает до 80 % переходов на сайты изданий. При этом сам «Дзен» стагнирует с сентября 2022 года, с момента, когда Яндекс продал его VK. Вывод VK: если ничего не делать, закроются негосударственные федеральные СМИ, и рынок монополизируют ТАСС, РИА «Новости» и RT.

Я даже не знаю, что тут сказать. Компания, которая не смогла развить купленный продукт, превратила его в никому не интересный тухляк, предлагает государству заставить весь рунет этот продукт использовать. А чтобы предложение звучало убедительнее, пугает тем, что без принудительных мер останутся только государственные СМИ (а чем, кстати, это хуже, чем транслировать госновости через Дзен?). То есть решение проблемы государственной монополии на информацию — усилить государственный контроль над информацией.

Классный подход. Чем-то напоминает «развитие» АвтоВАЗа за счёт гигантского «утильсбора» и помощь Почте России за счёт комиссии с маркетплейсов. И больше всего меня пугает то, что несмотря на очевидную вроде бы несуразность, инициативу могут принять.

Почему это важно

Давайте разберём, что здесь происходит на самом деле.

Это не спасение медиа. Если бы целью было поддержать СМИ, достаточно было бы грантовой программы или налоговых льгот. Здесь же строится инфраструктура принудительной дистрибуции контента с единым оператором, назначаемым правительством, и государственным отбором источников.

Это не для удобства пользователей. Ни один пользователь Ozon или Wildberries не приходит туда за новостями. Обязательный виджет — это навязывание контента там, где его не ждут и не хотят. Это не сервис, а инструмент воздействия.

Это настоящий контроль повестки. Ключевой пункт всей инициативы — правительство отбирает «правильные» СМИ. Не алгоритм, не пользователь, не редакция площадки. Правительство. Это значит, что из информационного блока, который увидят десятки миллионов людей ежедневно, будут исключены все источники, не вписывающиеся в официальную линию.

Это способ увеличить доход VK. «Дзен» стагнирует, и VK нашла элегантный способ решить коммерческую проблему за счёт законодательного принуждения. Заставить конкурентов — маркетплейсы, соцсети, видеосервисы — бесплатно отдавать трафик «Дзену», да ещё и делиться рекламной выручкой, 40 % которой растворяются в недосказанности презентации.

Контекст: это не первый шаг

Эту инициативу нельзя рассматривать изолированно. Она ложится в ряд последовательных шагов по ужесточению контроля над информационным пространством: замедление и блокировки платформ, закон о «приземлении», реестры блогеров и прочие запретительные меры, количество которых уже сложно даже посчитать. Каждый следующий шаг выглядит «логичным продолжением» предыдущего, и каждый сужает пространство для независимой информации.

Национальная новостная платформа — это следующий уровень. Не просто блокировка нежелательного, а принудительная трансляция желательного. Разница принципиальная: одно дело — убрать из поля зрения то, что не нравится власти. Другое — заставить каждую крупную площадку транслировать только то, что власть считает нужным.

Вывод

Перед нами проект, в котором коммерческие интересы VK идеально совпали с желанием государства контролировать информацию. VK получает принудительный трафик и рекламные деньги. Государство получает единый канал доставки утверждённой повестки на все крупные площадки рунета. Пользователь получает виджет, который он не просил, с новостями, которые отобрали за него.

Самое тревожное — не конкретный законопроект, а направление движения. Когда государство решает, что вам читать, где вам это читать и через какой единственный канал это до вас дойдёт, — это уже не регулирование медиарынка. Это конструирование информационной реальности.

Источники:

• Коммерсантъ — «Дзен» претендует на статус Национальной новостной платформы
• Хабр — На базе «Дзена» предложено создать «Национальную информационную платформу»
• Фонтанка — Национальная новостная платформа на базе «Дзена»
• CNews — В России построят национальную новостную платформу
• Retail.ru — Маркетплейсы могут заставить делиться трафиком с «Дзеном»

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

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

Рациональные люди не свободны от суеверий. Они просто маскируют их под «привычки», «осторожность» и «здравый смысл». Механизм тот же — магическое мышление: вера в то, что определённые действия или слова влияют на реальность способом, который невозможно объяснить причинно-следственной связью. Обёртка другая, содержимое то же.

Сглазить

Страх сглазить — пожалуй, самое живучее суеверие в арсенале современного человека с высшим образованием. Оно не выглядит как суеверие. Оно выглядит как воспитание.

Не рассказывать о планах, пока не сбылись. Не хвастаться здоровьем. Не говорить «у нас всё отлично» — а отвечать «нормально», «потихоньку», «грех жаловаться». На вопрос «как дела?» — что угодно, только не правду, если правда хорошая. Формально — скромность. Привычка. Осторожность. Фактически — глубокая, неартикулированная уверенность, что вселенная подслушивает и наказывает за самоуверенность. Сказал «всё хорошо» — и вот, пожалуйста: словно кто-то наверху услышал и решил это исправить.

Примеры — на каждом шагу, стоит только начать замечать. Беременность не обсуждают до двенадцати недель. Медицинское обоснование для этого есть: первый триместр действительно рискованный. Но давайте будем честны — большинство людей боятся не статистики выкидышей. Они боятся сглазить. При увольнении скрывают новое место работы, потому что позавидуют. Сделку не обсуждают до подписания, и дело не в коммерческой тайне, а в смутном ощущении, что слова способны разрушить то, что ещё не оформилось. «Тьфу-тьфу-тьфу» произносится на автопилоте, машинально, как рефлекс — и именно поэтому оно показательно. Суеверие, которое настолько впиталось, что уже не воспринимается как суеверие.

Обратите внимание на язык: мы не говорим «я боюсь, что не получится». Мы говорим «не хочу загадывать». Первое — признание тревоги. Второе — рациональная осторожность. Разница в формулировке, но не в том, что за ней стоит. Под «не буду загадывать» лежит тот же древний, довербальный страх: не дразни судьбу. Просто он переодет в деловой костюм.

Ритуал подготовки как оберег

«Если я возьму зонт, дождя не будет». Фраза, которую каждый произносил хотя бы раз, и не всегда в шутку.

Это не наблюдение. Это заклинание.

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

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

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

Логика та же, что у шамана, рисующего бизона на стене пещеры перед охотой. Он тоже «готовился». И если его спросить, он бы, вероятно, объяснил это не магией, а «настройкой перед делом» — и мы бы снисходительно кивнули, понимая, что это суеверие. А потом пошли бы собирать аптечку в дорогу, тихо надеясь, что сам факт её наличия защитит от необходимости ею воспользоваться.

Вещи, которые «работают»

У каждого есть вещи, которые «работают». Любимая кружка, с которой почему-то лучше работается. Определённый плейлист для сосредоточенности — не фоновый шум, а именно этот, конкретный, проверенный. Кресло в кафе — не то, что у окна, а вот то, в углу, с потёртой обивкой, и если оно занято — день уже чуть хуже. Привычный маршрут до магазина, хотя есть короче. Конкретная ручка, футболка, место за столом. Сторона кровати, порядок, в котором складываются вещи в рюкзак.

Рациональный человек объяснит это «привычкой» и «якорением» и будет отчасти прав. Привычное окружение снижает когнитивную нагрузку, мозг не тратит ресурсы на ориентирование и может сосредоточиться на задаче. Всё логично. Нейронаука подтвердит: стабильный контекст облегчает вход в рабочее состояние. Никакой магии.

Но если кружка разобьётся, этот же рациональный человек расстроится несоразмерно потере предмета стоимостью пятьсот рублей. Не из-за денег. Не из-за неудобства — можно купить такую же за полчаса. Расстроится потому, что кружка была тотемом. Она нагружена значением, которое не имеет отношения к керамике и объёму. Это не сосуд для чая, это «вещь, с которой получается». И заменить её нельзя, потому что «такая же» — это не та самая.

Отличие от религиозного амулета ровно одно: мы знаем «правильное» объяснение. Мы можем сказать «это якорение, описанное в когнитивной психологии». Но поведение то же самое. Утрата вещи вызывает тревогу, несоразмерную её стоимости. Замена не годится, даже если объективно идентична. Мы ведём себя так, будто в предмете живёт что-то, чего нет в его копии. Это и есть магическое мышление, просто мы называем его «ассоциацией».

Почему умные люди не защищены

Можно было бы списать всё это на культурный багаж, привычки, воспитание. Но когнитивная наука показывает кое-что менее утешительное: дело не в культуре, а в устройстве мозга. Механизмы, стоящие за суевериями, встроены в саму архитектуру мышления. Предвзятость подтверждения — мы запоминаем совпадения и забываем несовпадения. Один раз не взял зонт и попал под дождь — запомнил на годы. Двадцать раз не взял и не попал — не заметил. Иллюзия контроля — Эллен Лангер в 1975 году показала, что люди ведут себя так, будто могут повлиять на бросок кубика: ставки увереннее, если бросаешь сам, а не наблюдаешь. Апофения — термин психиатра Клауса Конрада — способность видеть паттерны и связи там, где их объективно нет. Три хороших дня подряд после покупки нового ежедневника — и вот уже ежедневник «работает».

Даниэль Канеман в «Думай медленно… решай быстро» разложил это на две системы. Быстрое, интуитивное мышление — Система 1. Медленное, аналитическое — Система 2. Суеверие — продукт первой. Она видит корреляцию и мгновенно, без усилий делает вывод о причинности. Надел «счастливую» рубашку — собеседование прошло хорошо — значит, рубашка помогла. Вторая система могла бы поправить, но ей лень: она энергозатратна и включается только когда мы специально заставляем себя думать критически. А кто будет критически думать о рубашке?

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

Глупый человек стучит по дереву и знает, что это суеверие. Умный стучит по дереву и объясняет это «мышечной привычкой», «социальным ритуалом, который я выполняю иронически», или «способом снизить тревожность через физическое действие». Объяснение красивее. Результат тот же — он стучит.

Более того: чем умнее человек, тем изощрённее защита. Человек с одним высшим стучит по дереву со смущённой улыбкой. Человек с двумя объясняет это теорией ожиданий и управлением когнитивной нагрузкой. Человек с кандидатской степенью стучит по дереву, а потом пишет об этом рефлексивное эссе. Глубина понимания растёт. Деревянная поверхность остаётся той же.

Суеверие эффективности

Есть целый пласт суеверий, замаскированный настолько хорошо, что его принято считать не просто нормой, а добродетелью. Наша эпоха возвела в культ веру в ритуалы продуктивности, и мало кто замечает, что это именно вера.

Правильное утро: подъём в 5:30, холодный душ, медитация, дневник благодарности, стакан воды с лимоном. Правильный ежедневник — не любой, а конкретной системы, с правильной разметкой. Правильная ручка — не шариковая за тридцать рублей, а та, которой «приятно писать». Правильное приложение для задач — не то, которое удобно, а то, в которое веришь. Правильная музыка. Правильное рабочее место. Правильная последовательность.

Если день не задался, первая мысль: я нарушил ритуал. Проснулся позже, пропустил медитацию, не записал цели на день — и вот, пожалуйста, всё пошло наперекосяк. Причинно-следственная связь очевидна. Для Системы 1.

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

Это буквально магическое мышление: определённая последовательность действий вызывает определённый результат, даже если причинной связи между ними нет. Но ощущение контроля — «я сделал всё правильно» — настолько ценно, что мы цепляемся за него, как средневековый крестьянин за молитву перед посевом.

Причём ритуал устроен хитро: если день удался, значит, ритуал помог. Если не удался, значит, ритуал нарушил или выполнил недостаточно тщательно. Система нефальсифицируема. Это не наука. Это именно вера со своими священными текстами (книги про привычки), пророками (авторы курсов продуктивности) и обрядами (утренние рутины).

Индустрия продуктивности продаёт не инструменты. Она продаёт амулеты. Красивые, хорошо упакованные, с научными ссылками на обложке, но по сути амулеты. «Делай вот это каждое утро, и жизнь наладится.» Формула заклинания, прикрытая языком лайфхаков. Отличие от молитвенника только в шрифте и цене подписки.

Полезное суеверие

Было бы удобно на этом закончить, мол, мы все немного суеверны, давайте это признаем и посмеёмся. Но есть финальный поворот, который всё усложняет.

Некоторые суеверия действительно «работают». Не в смысле «влияют на реальность», а в смысле «влияют на нас, а мы влияем на реальность». Это важное различие, и оно всё запутывает.

Плацебо — не «самовнушение для слабых». Это реальный, измеримый, воспроизводимый эффект. Если ритуал снижает тревожность, он объективно улучшает результат. Лисанн Дамиш с коллегами в 2010 году провели серию экспериментов: участники, которым давали «счастливый» мяч для гольфа или говорили «скрести пальцы», показывали лучшие результаты в моторных и когнитивных задачах. Не потому, что мяч волшебный. Потому что ритуал повышал уверенность в себе и снижал тревожность, а это уже влияло на результат.

Спортсмены с предстартовыми ритуалами выступают лучше. Это не магия, а переключение фокуса с тревоги на действие. «Счастливая» кружка действительно помогает сосредоточиться через якорение. Утренний ритуал действительно задаёт тон дня через снижение неопределённости. Даже пресловутое «тьфу-тьфу-тьфу» выполняет функцию: отмечает тревогу, признаёт её и символически закрывает вместо того чтобы позволить ей расти в фоновом режиме.

Суеверие работает не как магия, а как хак нервной системы. Обход рационального контроля, который приносит реальный, измеримый результат. Мы обманываем себя, и этот обман полезен. Причём, что интересно, плацебо работает даже когда пациент знает, что принимает пустышку: так называемый «открытый плацебо» всё равно даёт эффект. Мозгу, похоже, достаточно самого ритуала даже если рациональная часть отдаёт себе отчёт в происходящем.

И тут возникает парадокс, из-за которого всю эту конструкцию нельзя просто разоблачить и отбросить.

Если суеверие работает через плацебо, а мы знаем, что это плацебо, оно всё ещё суеверие? Или уже инструмент? Если я стучу по дереву, понимаю, что это не влияет на реальность, но чувствую, как снижается тревога, я суеверный или практичный? Если кружка помогает мне работать и я знаю почему, это магическое мышление или осознанное использование когнитивных механизмов?

Граница между суеверием и инструментом проходит, видимо, через осознанность. Суеверие — это когда веришь, что ритуал влияет на мир. Инструмент — когда понимаешь, что ритуал влияет на тебя. Звучит чётко. На практике же размыто до невозможности.

Потому что осознанность — штука ненадёжная. Сегодня я «иронически» стучу по дереву. Завтра забываю про иронию. Послезавтра ловлю себя на искреннем беспокойстве, когда деревянной поверхности поблизости нет. Осознанность — не выключатель, а диммер, и его ручка постоянно ползёт сама.

А главное — вопрос, с которого всё начиналось: если я всё это знаю и понимаю, — почему мне всё равно не хочется говорить вслух, что всё идёт хорошо?

Может быть, рациональный человек отличается от суеверного не отсутствием суеверий, а качеством объяснений, почему его суеверия «не считаются».

Тьфу-тьфу-тьфу.

Текст «Войны и мира» в UTF-8 занимает около 3,2 МБ. Команда gzip сжимает его до 1,2 МБ — почти втрое. HTML-страница типичного сайта проходит через Brotli и уменьшается в 5–7 раз, прежде чем браузер получит первый байт. Образ Docker, ядро Linux, бэкап базы данных — всё хранится и передаётся в сжатом виде. Сжатие настолько вездесуще, что мы его не замечаем.

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

Простейшая идея: сжимать повторы

Интуиция подсказывает: если в данных есть повторяющиеся фрагменты, их можно записать короче. Самый наивный подход — RLE (Run-Length Encoding), кодирование длин серий: вместо AAAAAABBB написать 6A3B.

// RLE: кодирование длин серий
fn rle_encode(data: &[u8]) -> Vec<u8> {
    let mut result = Vec::new();
    let mut i = 0;
    while i < data.len() {
        let ch = data[i];
        let mut count = 1u8;
        while i + (count as usize) < data.len()
            && data[i + (count as usize)] == ch
            && count < 9
        {
            count += 1;
        }
        result.push(b'0' + count);
        result.push(ch);
        i += count as usize;
    }
    result
}

Вход:  "AAABBBCCDDDDDDEEEF" (18 байт)
RLE:   "3A3B2C6D3E1F"       (12 байт, 67 %)

RLE работает отлично на данных с длинными сериями одинаковых байт, например, на изображениях с большими однотонными областями. Но на обычном тексте он бесполезен: в слове "hello" нет длинных повторов, и RLE только увеличит размер. Нужен другой подход.

Энтропия: сколько информации в ваших данных

В 1948 году Клод Шеннон опубликовал статью «A Mathematical Theory of Communication» и ввёл понятие, которое определило всю дальнейшую теорию сжатия — энтропию:

H = −Σ P(xᵢ) × log₂(P(xᵢ))

Энтропия H — среднее количество бит информации на символ. Что это значит на практике? Посчитаем:

fn shannon_entropy(data: &[u8]) -> f64 {
    let mut freq = [0usize; 256];
    for &b in data {
        freq[b as usize] += 1;
    }
    let len = data.len() as f64;
    let mut h = 0.0;
    for &f in &freq {
        if f > 0 {
            let p = f as f64 / len;
            h -= p * p.log2();
        }
    }
    h
}

"aaaaaaaaaa"    H = 0.000 бит/символ
"aababcabcd"    H = 1.846 бит/символ
"hello world"   H = 2.845 бит/символ
"abcdefghij"    H = 3.322 бит/символ

Строка из одних a имеет энтропию 0. Зная первый символ, вы знаете все остальные. Строка из десяти различных символов имеет самую большую энтропию для этого алфавита: log₂(10) ≈ 3,32 бита. Каждый символ несёт максимум информации, предсказать следующий невозможно.

Теорема Шеннона о кодировании источника утверждает: никакой алгоритм без потерь не может сжать данные ниже их энтропии. Это фундаментальный предел, как скорость света для передачи сигнала.

Английский текст имеет энтропию около 1–1,5 бит на символ (с учётом частотности пар и троек букв). ASCII использует 8 бит на символ. Разница — 5–7 крат — это и есть теоретический запас для сжатия.

Код Хаффмана: частые символы — короткие коды

В 1952 году студент MIT Дэвид Хаффман получил от профессора Роберта Фано задание на курсовую: придумать способ закодировать набор символов двоичными последовательностями так, чтобы итоговое сообщение занимало как можно меньше бит. Фано сам работал над этим совместно с Шенноном, и их метод (Shannon–Fano coding) давал хорошие, но не оптимальные результаты. Хаффман нашёл решение, строя кодовое дерево снизу вверх — от наименее частых символов к наиболее частым.

Идея: частым символам — короткие коды, редким — длинные. Возьмём строку "abracadabra":

// Частотный анализ "abracadabra"
let text = b"abracadabra";
let mut freq: HashMap<u8, usize> = HashMap::new();
for &b in text.iter() {
    *freq.entry(b).or_insert(0) += 1;
}

'a': 5  (45 %)  →  код: 0       (1 бит)
'b': 2  (18 %)  →  код: 10      (2 бита)
'r': 2  (18 %)  →  код: 110     (3 бита)
'c': 1  ( 9 %)  →  код: 1110    (4 бита)
'd': 1  ( 9 %)  →  код: 1111    (4 бита)

В ASCII каждый символ занимает 8 бит, и "abracadabra" — это 88 бит. С кодом Хаффмана: 5×1 + 2×2 + 2×3 + 1×4 + 1×4 = 23 бита. Сжатие в 3,8 раза.

Ключевое свойство — префиксность: ни один код не является началом другого. Код 0 (для a) не начинает код 10 (для b) — потому что 0 это полный код, а 10 начинается с 1. Благодаря этому поток бит можно декодировать однозначно, без разделителей: 010011011101111010 → a b r a c a d a b r a.

Код Хаффмана оказался строго оптимальным среди префиксных кодов. Работу засчитали как курсовую с освобождением от финального экзамена.

LZ77: сжимать не символы, а повторы подстрок

Алгоритм Хаффмана работает с частотами отдельных символов. Но в реальных данных избыточность проявляется на уровне целых фрагментов: повторяются слова, конструкции, паттерны. В 1977 году Абрахам Лемпель и Яков Зив предложили принципиально другой подход.

Алгоритм LZ77 поддерживает скользящее окно — буфер уже обработанных данных. Когда в потоке встречается фрагмент, который уже есть в окне, вместо самого фрагмента записывается ссылка: «вернись на N байт назад и скопируй M байт».

Вход: A B C A B C A B C
           ───────
           совпадение с позиции 0, длина 6

Выход: A B C (ссылка: смещение=3, длина=6)

Девять байт превращаются в три литерала и одну ссылку. На длинных текстах с повторяющимися словами и фразами это даёт серьёзное сжатие.

LZ77 не требует предварительного анализа всех данных, он работает потоково, обрабатывая вход слева направо. В 1978 году Лемпель и Зив опубликовали LZ78, использующий явный словарь вместо окна. На основе LZ78 Терри Уэлч создал LZW (1984), ставший основой GIF. LZW был запатентован, что в итоге привело к созданию формата PNG как свободной альтернативы.

DEFLATE: объединяя два подхода

Следующий логичный шаг — совместить оба метода. Именно это сделал Фил Кац, программист из Милуоки, в алгоритме DEFLATE для своего архиватора PKZIP 2.0:

1. LZ77 находит повторяющиеся подстроки и заменяет их ссылками.
2. Код Хаффмана кодирует получившийся поток — и литералы, и ссылки — присваивая частым элементам короткие коды.

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

DEFLATE стал основой трёх популярных форматов: gzip (1992) для HTTP и логов, ZIP для архивов, PNG для изображений. Жан-лу Гайи и Марк Адлер реализовали его в библиотеке zlib (1995), которая стала одной из самых распространённых библиотек в истории. Спецификация зафиксирована в RFC 1951 (1996).

Сжатие gzip сегодня выполняется в одну строка кода:

// Go: сжатие gzip из стандартной библиотеки
data := []byte(strings.Repeat("Hello, World! ", 500)) // 7000 байт

var buf bytes.Buffer
w := gzip.NewWriter(&buf)
w.Write(data)
w.Close()

// Результат: 7000 → 63 байт (0.9 %)

// Уровни сжатия: скорость vs степень
// BestSpeed (1):        7000 → 65 байт
// Default (6):          7000 → 63 байт
// BestCompression (9):  7000 → 63 байт

Обратите внимание: разница между уровнями 1 и 9 по размеру — всего 2 байта, а по времени — в разы. Уровень по умолчанию выбран не случайно.

Теоретический потолок: почему универсальный компрессор невозможен

Раз DEFLATE сжимает текст в десятки раз, может, можно сжать ещё? А потом сжать результат? И так до бесконечности?

Нет. И доказательство элементарно.

Строк длины n бит существует ровно 2^n. Строк длины меньше n бит — всего 2^n − 1. По принципу Дирихле невозможно каждой строке длины n сопоставить уникальную строку меньшей длины — «ящиков» не хватает. Любой алгоритм, который сжимает одни строки, обязан увеличивать другие.

В 1960-х годах три учёных независимо пришли к одному и тому же выводу. Рэй Соломонофф (1960), Андрей Колмогоров (1965) и Грегори Хейтин (1969) определили алгоритмическую сложность строки как длину кратчайшей программы, которая её порождает. Из этого определения следует: большинство строк несжимаемы. Случайная строка с высокой вероятностью не содержит закономерностей, которые можно было бы использовать, и это, собственно, формальное определение случайности.

Хейтин описал результат так: «Берём теорию информации Шеннона и теорию вычислимости Тьюринга, помещаем в шейкер для коктейлей и энергично перемешиваем».

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

ZIP-бомбы: сжатие как оружие

Ограничение DEFLATE — максимальная степень сжатия не более 1032:1. Но формат ZIP позволяет вкладывать архивы в архивы. Классическая ZIP-бомба 42.zip использует именно это: файл размером 42 КБ содержит пять уровней вложенных ZIP-архивов, по 16 файлов на каждом уровне. На нижнем уровне каждый файл распаковывается до 4,3 ГБ. Итого после полной распаковки — ~4,5 петабайт. Цель — вывести из строя антивирус или любую программу, которая рекурсивно распаковывает архивы.

Защита казалась простой: ограничить глубину рекурсивной распаковки. Но в 2019 году Дэвид Фифилд представил на конференции USENIX WOOT нерекурсивную ZIP-бомбу. Его метод использует особенность формата ZIP: несколько файловых записей в центральном каталоге могут ссылаться на один и тот же блок сжатых данных. Результат — квадратичный рост размера при распаковке за один проход, без вложенности.

42 КБ   → 5,5 ГБ   (степень 129 000:1)
10 МБ   → 281 ТБ   (степень 28 000 000:1)
46 МБ   → 4,5 ПБ   (с расширениями Zip64)

Всё это — стандартный DEFLATE, один уровень вложенности, никакой рекурсии. Знание того, как работает сжатие, позволяет и защищаться, и атаковать.

От gzip к zstd: смена поколений

gzip, созданный Гайи и Адлером в 1992 году, продержался стандартом HTTP-сжатия и сжатия логов тридцать лет. Он прост, надёжен и поддерживается буквально везде. Но за это время процессоры изменились неузнаваемо, а алгоритм — нет. Появились замены.

Zstandard (Янн Колле, 2016)

Янн Колле, инженер Meta, создал zstd — алгоритм на основе словарного сжатия и конечных автоматов (FSE — Finite State Entropy), оптимизированный под параллельное исполнение на современных CPU. При том же уровне сжатия zstd в 3–5 раз быстрее gzip. При той же скорости сжимает лучше.

Внедрение шло быстро:

• Linux kernel 4.14 (2017) — сжатие модулей;
• Arch Linux (2020) — переход с xz на zstd для пакетов;
• AWS S3 — внутреннее сжатие (~30 % экономия на экзабайтах данных);
• Chrome 123 и Firefox 126 (2024) — Content-Encoding: zstd;
• ; Windows 11 (октябрь 2023) — поддержка в Проводнике.

Колле также создал и алгоритм LZ4, оптимизированный под скорость декомпрессии: более 4 ГБ/с на одном ядре. LZ4 используется в ядре Linux, ZFS, десятках баз данных. Он же создал и xxHash. Забавный факт: LZ4 начинался как побочный проект, когда Колле работал в маркетинговом отделе телеком-компании Orange.

Brotli (Google, 2015)

Жирки Алакуйала и Золтан Сабадка из Google создали Brotli изначально для сжатия веб-шрифтов (WOFF2), а затем обобщили для HTTP. Ключевая идея — предопределённый словарь из часто встречающихся фрагментов HTML, CSS и JavaScript. Для статических ресурсов Brotli даёт лучшую степень сжатия, чем gzip и zstd, но медленнее на высоких уровнях компрессии.

По данным HTTP Archive (январь 2024): Brotli и gzip используются примерно поровну (~40 % каждый), zstd растёт (~2 %), около 11 % ответов не сжаты.

Сжатие в Go, Rust и Zig

Go: всё в стандартной библиотеке

Go включает compress/gzip, compress/zlib, compress/flate (DEFLATE), compress/lzw и compress/bzip2 (только декомпрессия). Для продакшена часто используют klauspost/compress, совместимый по API, но в 2–5 раз быстрее. Этот же пакет содержит чистую реализацию zstd на Go.

import "compress/gzip"

// Сжатие
var buf bytes.Buffer
w := gzip.NewWriter(&buf)
w.Write(data)
w.Close()

// Распаковка
r, _ := gzip.NewReader(&buf)
io.Copy(os.Stdout, r)

Rust: экосистема крейтов

Крейт flate2 — обёртка над DEFLATE с четырьмя бэкендами: miniz_oxide (чистый Rust, по умолчанию), zlib-rs (чистый Rust, самый быстрый), zlib-ng (C через FFI) и cloudflare_zlib.

Отдельного упоминания заслуживает zlib-rs — проект, финансируемый ISRG (создатели Let’s Encrypt). В феврале 2025 года он обогнал zlib-ng: декомпрессия на 6–10 % быстрее, компрессия на 6 % быстрее на уровне по умолчанию. Чистый Rust, без unsafe в горячих путях, с автоматическим обнаружением SIMD.

Zig: минимализм

В Zig 0.12 стандартная библиотека содержала std.compress с поддержкой deflate, gzip, zlib, xz и zstd. В Zig 0.15 компрессия была удалена (декомпрессия осталась) как часть масштабного пересмотра системы ввода-вывода. Сообщество создало библиотеку comprezz, извлечённую из стандартной библиотеки 0.14 и адаптированную под новые интерфейсы.

Полные примеры: compress_demo.rs, compress_demo.go, compress_demo.zig.

Что выбрать на практике

При выборе алгоритма сжатия ключевой вопрос — где узкое место. Если вы отдаёте статические ресурсы по HTTP (JavaScript-бандлы, CSS, шрифты), имеет смысл сжать их один раз Brotli на максимальном уровне и закешировать результат. Время компрессии здесь не критично — файл сжимается при деплое, а отдаётся тысячам клиентов.

Для динамических ответов, которые генерируются на лету, расклад другой. Здесь важна скорость сжатия, и zstd на уровне 3–5 даёт лучший баланс: сжимает не хуже gzip-9, но в разы быстрее. gzip при этом остаётся разумным fallback — его понимают все клиенты, включая древние.

Для архивов и бэкапов zstd заменяет gzip практически во всех сценариях. Если же критична скорость распаковки (игровые ресурсы, которые нужно загрузить за кадр, swap-раздел, горячий кеш), стоит посмотреть на LZ4 — он жертвует степенью сжатия, но декомпрессирует со скоростью более 4 ГБ/с.

Отдельная ловушка — уровни сжатия. Между уровнями 1 и 6 разница в размере ощутима. Между 6 и 9 почти незаметна, а разница по времени — в разы. Уровень по умолчанию в большинстве реализаций выбран не случайно. Он уже находится в точке, где дальнейшее повышение уровня почти не уменьшает размер, но заметно замедляет процесс.

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

Заключение

Сжатие данных — область, где теория и практика связаны напрямую. Шеннон определил предел в 1948 году. Хаффман приблизился к нему в 1952-м. Лемпель и Зив добавили словарный подход в 1977-м. DEFLATE объединил оба метода в 1990-х и держится стандартом до сих пор.

Zstd — первая замена, набравшая критическую массу: от ядра Linux до браузеров и облачных хранилищ. Но фундаментальный результат Колмогорова остаётся: универсального компрессора не существует. Каждый алгоритм — компромисс между степенью сжатия, скоростью и объёмом памяти. Выбирайте тот, который соответствует вашей задаче.

Источники

• A Mathematical Theory of Communication (Shannon, 1948) — статья Шеннона
• A Method for the Construction of Minimum-Redundancy Codes (Huffman, 1952) — код Хаффмана
• A Universal Algorithm for Sequential Data Compression (Ziv & Lempel, 1977) — LZ77
• RFC 1951: DEFLATE Compressed Data Format Specification — спецификация DEFLATE
• A better zip bomb (David Fifield, 2019) — нерекурсивная ZIP-бомба
• Zstandard (GitHub) — исходный код zstd
• zlib-rs is faster than C (2025) — результаты zlib-rs
• Kolmogorov Complexity (Wikipedia) — алгоритмическая сложность
• Choosing Between gzip, Brotli and zStandard (Paul Calvano, 2024) — сравнение алгоритмов для веба