Андрей Жаркевич

Вот и всё, что останется после меня — путеводитель по цифровому наследству в России

2026-06-04T20:21:51.560Z

У среднего россиянина за двадцать лет интернет-жизни накопилось примерно столько цифровых активов, сколько физических за всю историю его семьи. Тридцать-сорок аккаунтов в разных сервисах. Несколько тысяч фотографий, которые лежат не в альбоме на полке, а в облаке. Переписка с близкими за десять лет в Telegram и других мессенджерах. Документы на Яндекс и Гугл Диске. Возможно, криптокошелёк с какими-то активами. Деньги в банковских приложениях. Подписки, которые продолжают списываться. Электронная подпись для общения с налоговой. Аккаунт на Госуслугах — главный цифровой паспорт российского человека сегодня, через который проходят все взаимодействия с государством.

Что произойдёт со всем этим, если завтра вас не станет?

Если сильно упростить, то почти ничего. Российское право и российская инфраструктура цифровых сервисов сегодня устроены так, что родственники после смерти близкого оказываются перед непробиваемой стеной. Доступ к большинству аккаунтов получить невозможно. Деньги, которые лежат на счёте у умершего, придётся вытаскивать через нотариуса в течение полугода, и то не все и не всегда. Аккаунт Госуслуг останется висеть как зомби (буквально — в 2024 году обнаружилось, что в Сети идёт активная торговля «мёртвыми» аккаунтами Госуслуг). Криптокошелёк, к которому никто не знает seed-фразу, исчезнет навсегда. Переписку прочитать не сможет никто, если вы пользовались секретными чатами Telegram или мессенджерами с e2e-шифрованием. В случае с госмессенджером Макс ваши переписки будут храниться в течение полугода. Как, впрочем, и переписки в ВК и Одноклассниках.

Этот пост — попытка разобраться, что с этим делать. Я пройдусь по нормативным актам российского права в части цифровых активов (спойлер: отдельного закона про цифровое наследство в РФ нет), по главным сервисам и категориям — Госуслуги, банки, электронная подпись, криптовалюта, мессенджеры, почта, облачные хранилища, расскажу, что делают Apple и Google, и в финале дам практический протокол: что конкретно нужно сделать прямо сейчас, при жизни, чтобы после нашей смерти близкие не потеряли всё накопленное.

Сразу оговорюсь: тема малоприятная. О собственной смерти думать не любит никто. Но разобраться в этом до того, как стало поздно, — обязанность ответственного взрослого человека, особенно если у него есть семья. Я попробую сделать материал максимально практичным.

1. Что говорит российское право

Главная статья, которая регулирует наследство в России, — статья 1112 Гражданского кодекса РФ. Она устанавливает, что в состав наследства входят «вещи, иное имущество, в том числе имущественные права и обязанности». Личные неимущественные права (например, право авторства, право на имя) в наследство не переходят.

«Цифровые активы» в статье 1112 прямо не указаны. Это создаёт первую большую проблему.

В 2019 году в ГК была добавлена статья 141.1 «Цифровые права» (через ФЗ от 18 марта 2019 года № 34-ФЗ, действует с 1 октября 2019 года). Цифровое право — это обязательственное и иное право, реализуемое в правилах информационной системы. Эта статья создала юридическую категорию, но не сказала ничего конкретного про наследование. Применяются общие нормы наследственного права (раздел V ГК РФ).

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

С персональными данными ситуация частично описана. Часть 7 статьи 9 ФЗ-152 «О персональных данных» устанавливает: согласие на обработку персональных данных умершего дают его наследники (в порядке очередей по статьям 1142–1145 и 1148 ГК), если такое согласие не было дано при жизни. Что делать, если наследников нет, закон не разъясняет.

Отдельного закона о цифровом наследстве в России не существует. Депутаты периодически вносят предложения, Минюст обсуждает закрепление понятия, но пока на уровне законопроектов. Главный практический инструмент — закрытое завещание (статья 1126 ГК), в которое юристы рекомендуют включать перечень аккаунтов, место хранения паролей и инструкции для наследников. Опись наследственного имущества (статья 1171 ГК) формально позволяет нотариусу включать цифровые активы, но порядок не регламентирован, и на практике это получается у нотариусов с трудом.

2. Госуслуги: главный аккаунт российского человека

Аккаунт на Госуслугах в 2026 году — это, наверное, самая важная единица цифровой идентичности россиянина. Через него проходит общение с налоговой, с пенсионным фондом, с МФЦ, с медициной, с госпошлинами, с водительскими правами, с регистрацией недвижимости, с детскими садами, со школами. Без Госуслуг полноценное существование в современной России затруднительно. И с декабря 2025 года через Госуслуги обязательна авторизация в национальном мессенджере МАКС.

Что происходит с аккаунтом Госуслуг после смерти? Автоматического удаления нет. Министерство цифрового развития называет два сценария закрытия аккаунта:

По сведениям из ЗАГСа. Когда ЗАГС регистрирует смерть, информация попадает в реестры, и теоретически аккаунт может быть деактивирован автоматически. На практике это работает с задержкой и не всегда.
По обращению родственников. Близкие могут обратиться в МФЦ или в любой центр обслуживания Госуслуг (их список доступен на сайте gosuslugi.ru) со свидетельством о смерти, своим паспортом и документами, подтверждающими родство, — и запросить удаление аккаунта. Можно также отправить обращение через форму обратной связи на самом портале Госуслуг или позвонить в контакт-центр (8 800 100-70-10), но в большинстве случаев документы всё равно потребуют принести лично.

В 2024 году агентство URA.RU опубликовало материал о том, что в России активно идёт торговля «мёртвыми» аккаунтами Госуслуг. Аккаунт умершего человека, к которому никто не предъявил права, может оставаться активным годами. Через такой аккаунт мошенники получают доступ к МФЦ, оформляют кредиты, переоформляют недвижимость. После публикации Минцифры объявило, что готовит законопроект о принудительной деактивации аккаунтов Госуслуг через ФССП, Росреестр и нотариат. На момент написания этого поста (середина 2026 года) законопроект ещё не принят.

Практический вывод: сообщите близким, как обратиться в Минцифры для удаления аккаунта. И сами — пройдите в настройках Госуслуг, посмотрите, какие сервисы у вас привязаны, и составьте список (об этом — в финальном протоколе).

3. Биометрия и ЕБС

Параллельно с Госуслугами в России работает Единая биометрическая система (ЕБС), работа которой регулируется ФЗ от 29 декабря 2022 года № 572-ФЗ. Оператор — АО «Центр биометрических технологий» (постановление Правительства от 16 декабря 2022 года № 2326). В ЕБС хранятся образцы голоса, лица, отпечатков пальцев — для входа в банки, для удалённого открытия счетов, для прохода в МФЦ.

Что происходит с биометрией умершего человека в ЕБС? Публичная процедура удаления биометрических данных отсутствует. Это пробел регулирования — оператор ЕБС хранит данные, регламенты внутренние, но порядок их аннулирования по смерти открыто не описан. Скорее всего, биометрия остаётся в системе до окончания периода хранения (по закону — 10 лет с момента последнего использования или согласия), и физически удалить её ваш родственник не сможет.

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

4. Электронная подпись (КЭП)

Квалифицированная электронная подпись регулируется ФЗ от 6 апреля 2011 года № 63-ФЗ. Она нужна индивидуальным предпринимателям и руководителям организаций для общения с ФНС, для отчётности, для подписания договоров.

Статья 10 ФЗ-63 прямо запрещает передачу электронной подписи третьим лицам. Это значит, что даже если ваш супруг знает PIN-код от вашего токена с КЭП и технически может подписывать документы, делать это нельзя, поскольку уголовно наказуемо.

Статья 14 ФЗ-63 перечисляет основания прекращения сертификата КЭП. Смерть владельца формально подпадает под «иные случаи, предусмотренные законом» через прекращение правоспособности гражданина (статья 17 ГК). На практике:

КЭП, выданная Удостоверяющим центром ФНС (бесплатно для ИП и руководителей юрлиц), аннулируется автоматически после поступления сведений о смерти из ЗАГСа.
КЭП физического лица из коммерческого аккредитованного УЦ отзывается по обращению наследника с свидетельством о смерти. До этого момента она формально продолжает действовать.

Наследник не получает «КЭП наследодателя в наследство». Он может получить свою собственную КЭП, если ему нужно вести дела умершего (например, как наследник доли в ООО). Но это новый сертификат на нового человека.

Особый случай — индивидуальный предприниматель. Статус ИП по наследству не передаётся, ФНС снимает ИП с учёта автоматически. Все доверенности, выданные ИП, прекращают действие в момент смерти (пп. 5 п. 1 статьи 188 ГК). Долги по гражданским договорам переходят к наследникам по статье 1112 ГК. Налоговые долги ИП к наследникам не переходят (кроме имущественных налогов).

5. Банковские приложения и деньги

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

Главная норма — статья 1128 ГК «Завещательное распоряжение правами на денежные средства в банках». Вкладчик может оформить в банке распоряжение о том, кому из родственников после его смерти достанутся средства. Распоряжение приравнивается к завещанию.

Если завещательного распоряжения нет, наследники открывают наследственное дело у нотариуса (общая процедура по главе 63 ГК, в течение шести месяцев со дня смерти). Через нотариуса можно запросить ФНС о счетах наследодателя — банковская тайна снимается. Через нотариуса же можно получить до 100 000 рублей на похороны из имеющихся у умершего средств на банковских счетах (пункт 3 статьи 1174 ГК), не дожидаясь окончания шестимесячного срока. Важно понимать механизм: эти деньги не дают «откуда-то сверху» — они снимаются с собственных счетов наследодателя. Нотариус выносит постановление о возмещении расходов на достойные похороны, и банк по нему выдаёт сумму либо самому наследнику, либо иному лицу, указанному в постановлении (например, родственнику, который фактически организует и оплачивает похороны, даже если он не наследник). Если на счетах умершего денег нет, получить ничего нельзя: статья 1174 не создаёт государственного пособия, она только разрешает досрочное снятие со счёта умершего.

Сами банковские приложения — Сбербанк Онлайн, Т-Банк, Альфа, ВТБ — после получения банком информации о смерти владельца блокируются. Доступ через приложение прекращается. Все операции возможны только через офис банка или нотариуса.

Цифровой рубль — это новая форма безналичных денег, запущенная Центральным банком РФ. Поправки в законодательство о наследовании цифрового рубля внесены ФЗ от 24 июля 2023 года № 340-ФЗ, и порядок наследования вступил в силу с 1 августа 2024 года. По нему ЦБ обязан выдать цифровые рубли наследнику по постановлению нотариуса. Массовое внедрение цифрового рубля планируется с 1 сентября 2026 года. То есть к моменту, когда большинство россиян начнут им активно пользоваться, инструмент наследования формально уже будет работать.

6. Криптовалюта

С криптовалютой ситуация интересная. С одной стороны, криптовалюта в России не запрещена, но и не имеет статуса денежного средства. С другой — после принятия ФЗ от 31 июля 2020 года № 259-ФЗ «О цифровых финансовых активах и цифровой валюте» (действует с 1 января 2021 года) криптовалюта получила правовой статус имущества в смысле статьи 128 ГК.

Это значит, что криптовалюта входит в состав наследства по статье 1112 ГК. Позиция ФНС подтверждена судебной практикой: Девятый арбитражный апелляционный суд, кассационное определение Восьмого кассационного суда общей юрисдикции от 21 декабря 2023 года № 77-5316/2023, дело Мосгорсуда № 33-14530/2022, дела в Санкт-Петербурге — № 22-2616/2022.

Налоги: наследник криптовалюты не платит НДФЛ (пп. 18 статьи 217 НК РФ — наследство в общем случае не облагается НДФЛ). Но при последующей продаже наследованной криптовалюты налог уплатить придётся.

Главная практическая проблема — техническая, а не юридическая. Чтобы наследник получил криптовалюту, ему нужен доступ к кошельку. А доступ к самому кошельку — это seed-фраза (последовательность из 12–24 слов, которая позволяет восстановить кошелёк) или приватный ключ. Если seed-фразу никто не знает, никакое решение нотариуса не открывает кошелёк. Криптовалюта в нём останется навсегда, как сейф без ключа на дне океана.

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

Главная практическая мера: сохранение seed-фразы где-то вне головы в форме, к которой родственники смогут получить доступ после вашей смерти. Об этом подробно — в финальном протоколе.

7. Российские интернет-сервисы

С российскими сервисами правила отличаются от сервиса к сервису, и стоит пройтись по ним по очереди.

Яндекс. Российская корпорация (после реструктуризации 2024 года активы в РФ принадлежат российскому консорциуму). Включает Почту, Диск, Карты, Музыку, Кинопоиск и многое другое. После смерти владельца Яндекс не выдаёт доступ к содержимому аккаунта родственникам, ссылаясь на тайну переписки (статья 23 Конституции и статья 63 ФЗ «О связи»). Возможно только удаление аккаунта по обращению с свидетельством о смерти. Неактивный аккаунт автоматически удаляется примерно через два года.

ВКонтакте. Главная российская соцсеть. С ноября 2020 года введена мемориальная отметка — страница умершего человека помечается соответствующим знаком, аватар становится чёрно-белым, ставится памятная лента. Запрос на отметку делают родственники с документами. Доступ к содержимому страницы (личные сообщения, закрытые альбомы) не выдаётся.

Был известный судебный кейс: определение Верховного Суда РФ от 16 октября 2019 года № 308-ЭС19-17751. Финансовый управляющий банкротящегося гражданина потребовал у VK выдать пароли к социальным сетям должника. Верховный Суд отказал, сославшись на тайну переписки. Этот же прецедент применяется и в наследственных делах.

Mail.ru (теперь часть VK). Учётная запись связана с VK ID. Та же логика: удаление возможно, доступ — нет. Восстановление аккаунта возможно в течение примерно пяти лет неактивности.

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

8. Мессенджеры

Telegram. В РФ в 2026 году заблокирован (см. ранее в этом блоге). Технически для тех, кто использовал Telegram, есть встроенная функция автоматического самоуничтожения аккаунта — от 1 до 24 месяцев бездействия (по умолчанию — 6 месяцев). То есть аккаунт умершего человека через полгода после смерти исчезнет сам, если только семья не зайдёт в него с известным им номером телефона. Каналы, которые он администрировал, остаются с другими администраторами.

MAX. «Национальный мессенджер» (юридическое лицо — ООО «Коммуникационная платформа», входит в VK). С 1 сентября 2025 года предустановлен на новых российских устройствах согласно распоряжению Правительства от 21 августа 2025 года. С декабря 2025 года авторизация через Госуслуги. Публичный регламент наследования аккаунтов MAX на момент написания этого поста не опубликован. Скорее всего, будет применяться общая логика Госуслуг: после смерти — закрытие через свидетельство.

WhatsApp. Полностью заблокирован в РФ с 11 февраля 2026 года (через удаление доменов из НСДИ). До блокировки специальной российской процедуры наследования у него не было.

Signal, SimpleX. Эти мессенджеры заблокированы в РФ. Архитектурно у них нет наследования — они в принципе не идентифицируют пользователя через стороннюю систему, не хранят данных на серверах. Аккаунт умершего пользователя — это просто его устройство с установленным приложением. Если устройство сохранилось и у родственников есть код разблокировки, переписку можно прочитать. Если нет — нет.

9. Что хранится у операторов и провайдеров — независимо от вашей жизни

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

Федеральный закон от 12 августа 1995 года № 144-ФЗ «Об оперативно-розыскной деятельности» устанавливает общий порядок, по которому государственные органы могут получать доступ к данным граждан в интересах правоохранительной и контрразведывательной работы.

Статья 10.1 Федерального закона от 27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (введена ФЗ от 5 мая 2014 года № 97-ФЗ) ввела понятие «организатор распространения информации» (ОРИ). Под него попадают мессенджеры, почтовые сервисы, социальные сети и любые сервисы, через которые пользователи обмениваются сообщениями. ОРИ обязаны регистрироваться в Роскомнадзоре и хранить информацию о фактах приёма, передачи и обработки сообщений.

Федеральные законы от 6 июля 2016 года № 374-ФЗ и № 375-ФЗ (так называемый «пакет Яровой») внесли изменения в ФЗ от 7 июля 2003 года № 126-ФЗ «О связи» и в тот же ФЗ-149. Они радикально расширили объёмы и сроки обязательного хранения: операторы связи теперь обязаны хранить содержимое голосовых сообщений, текстов, изображений и видео — до шести месяцев (с 1 июля 2018 года), а метаданные (кто кому когда звонил, кто кому что отправил) — три года. ОРИ обязаны хранить содержимое сообщений до шести месяцев, метаданные до года, и предоставлять ФСБ ключи для расшифровки.

Технически реализация этих требований идёт через СОРМ (Систему оперативно-разыскных мероприятий) — обязательные аппаратные комплексы на стороне операторов, через которые проходит весь трафик. СОРМ существует в России в трёх поколениях: СОРМ-1 (с 1995 года, голосовая связь), СОРМ-2 (с 2000 года, интернет-трафик), СОРМ-3 (с 2014 года, расширенный сбор метаданных и биллинговых записей).

И теперь — главное в контексте этого поста. После вашей смерти эта информация не исчезает. Она продолжает храниться у операторов и ОРИ в течение установленных законом сроков, и продолжает быть доступной для государственных органов, имеющих право на её получение в рамках оперативно-розыскной деятельности (ФСБ, МВД, СВР, ФСО, Росгвардия, ФСИН в части их полномочий). Ваши родственники и наследники к этой информации доступа не получают ни по свидетельству о смерти, ни по решению нотариуса, ни по запросу адвоката.

Краткая сводка того, что и сколько хранится:

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

10. Облачные хранилища и зарубежные сервисы

Google. Главный инструмент — Google Inactive Account Manager (myaccount.google.com/inactive). Здесь вы заранее настраиваете: после какого периода бездействия (от 3 до 18 месяцев) что-то должно произойти с вашим аккаунтом. Можно назначить до десяти доверенных контактов, которым будет отправлено уведомление и (по вашему выбору) доступ к определённым сервисам. Можно настроить автоматическое удаление аккаунта через указанный срок. Для россиян это работает, если аккаунт не заблокирован в связи с санкциями.

Apple Legacy Contact (Доверенный контакт по наследству). Запущен с iOS 15.2 в декабре 2021 года. Вы назначаете доверенный контакт (например, супруг или ребёнок), система генерирует ключ доступа (access key), который вы передаёте контакту. После вашей смерти этот контакт со своим access key и свидетельством о смерти может получить доступ к содержимому вашего iCloud — фото, документам, заметкам — но не к платёжным данным и не к паролям из Keychain. Аккаунт удаляется через 3 года после смерти.

Apple Legacy Contact в РФ формально работает, потому что это не платный сервис. Однако часть платных функций iCloud в России Apple ограничил — например, новые подписки на iCloud+ оформить нельзя.

Microsoft / OneDrive. Аналогов Apple Legacy Contact и Google Inactive Account Manager у Microsoft нет. Доступ к аккаунту умершего родственники получают только через судебное решение или специальную процедуру Custodian of Records. Из России это технически возможно, но крайне сложно.

Dropbox, Notion, Slack — у всех есть собственные процедуры доступа после смерти, обычно требуют свидетельство о смерти и подтверждение родства. Из России — те же сложности, что у Microsoft.

11. Западные социальные сети

Facebook / Instagram. Принадлежат компании Meta, признанной в РФ экстремистской организацией; её деятельность запрещена. В России формально пользоваться этими сервисами с 2022 года нельзя. Для тех, кто продолжает через VPN, Meta предлагает Legacy Contact (с 2015 года) и опцию мемориализации страницы.

Twitter / X. Специальной процедуры нет. Родственники могут запросить деактивацию аккаунта.

LinkedIn. Деактивация по обращению родственников с документами.

12. Apple, Google и санкции

Отдельная боль россиян — санкционные ограничения на западные сервисы. С 2022 года часть платных функций Apple, Google и Microsoft недоступна для российских аккаунтов. Это в основном касается оплаты — невозможность подписаться на новые сервисы, обновить существующие подписки, купить приложения через App Store.

При этом базовые механизмы наследования продолжают работать (Apple Legacy Contact, Google Inactive Account Manager). По крайней мере, на момент написания этого поста. Гарантий на будущее нет: если санкции расширятся или Apple/Google решат прекратить обслуживание российских аккаунтов целиком, эти инструменты перестанут быть применимыми.

Это важно понимать: цифровое наследство, которое лежит в Apple iCloud или Google Drive, — это, по сути, заложник политической ситуации. Завтра доступ может пропасть. Поэтому критически важные данные стоит держать ещё и локально.

13. Что делать прямо сейчас: практический протокол

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

Шаг 1. Опись цифровых активов. Сядьте на час и составьте документ со списком:

все банковские счета и приложения (с указанием банков);
криптокошельки (с указанием платформ — Binance, Bybit, ByDFi и так далее, или локальный кошелёк);
аккаунты в социальных сетях и мессенджерах;
электронная почта (основная и резервные);
облачные хранилища (Яндекс.Диск, iCloud, Google Drive);
подписки (стриминговые сервисы, мобильная связь, аренда жилья через сервисы);
домены, которыми вы владеете;
профили на торговых площадках (Wildberries, Ozon, Avito);
профессиональные аккаунты (если вы программист, дизайнер, фрилансер).

Этот список должен лежать в физическом виде где-то, куда у вашей семьи есть доступ.

Шаг 2. Менеджер паролей и доступ для близких. Поставьте себе Bitwarden или KeePassXC и перенесите туда все пароли. У них принципиально разные модели передачи доступа в случае вашей смерти, и обе для российского пользователя имеют ограничения.

У Bitwarden есть встроенная функция Emergency Access: вы назначаете доверенный контакт, и после запроса с его стороны и заданного вами периода ожидания (от нескольких часов до месяцев) он получает либо просмотр, либо полный доступ к хранилищу. Но эта функция — часть платной подписки Premium, а оплачивать её из России сегодня сложно из-за санкционных ограничений на банковские карты. Если у вас есть способ оплатить (зарубежная карта, друзья за границей) — Emergency Access реально работает и удобен. Если нет — этой функции у вас не будет, и Bitwarden придётся использовать как обычное локальное хранилище.

У KeePassXC база паролей — это просто зашифрованный файл (.kdbx) на вашем устройстве. Встроенной функции «передать доступ после смерти» в нём нет в принципе: всё решается тем, где и как хранится мастер-пароль и сам файл. На практике это означает один или несколько таких приёмов: положить мастер-пароль в банковскую ячейку (см. шаг 3); хранить копию .kdbx-файла в нескольких местах (на домашнем компьютере, на флешке у родителей, в надёжном облаке); разделить мастер-пароль на части и отдать разным людям, чтобы доступ был возможен только при их согласовании. KeePassXC хорош тем, что не зависит ни от подписки, ни от внешнего сервиса, но всю «логику emergency access» придётся придумывать самостоятельно.

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

Шаг 3. Банковская ячейка с мастер-документом. Снимите банковскую ячейку. Цена зависит от банка, города, размера сейфа и срока аренды. В Москве у Сбера самые маленькие сейфы при длительной аренде обходятся примерно в 60–100 ₽ в сутки, у ВТБ — от 40 ₽ в сутки при аренде на два месяца и дольше. В годовом выражении это порядка 15–35 тысяч ₽ за самую маленькую ячейку. За крупные сейфы или короткие сроки заметно дороже. В региональных отделениях, как правило, дешевле столичных. Положите туда:

мастер-пароль от менеджера паролей;
seed-фразы криптокошельков (на бумаге, в нескольких экземплярах, и/или на стальных пластинах с выбитыми буквами — самодельных или купленных на Ozon/Wildberries под названиями «steel wallet» / «crypto seed plate»; они переживают пожар и затопление, в отличие от бумаги);
список цифровых активов;
инструкции для семьи.

Доступ к ячейке оформите так, чтобы после вашей смерти супруг или родители смогли её открыть по свидетельству о смерти.

Шаг 4. Закрытое завещание у нотариуса. Статья 1126 ГК. Стоимость в 2026 году — тариф 100 рублей плюс услуги правового и технического характера 1500–2500 рублей. В завещании укажите:

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

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

Шаг 5. Apple Legacy Contact и Google Inactive Account Manager. Если вы пользуетесь iCloud или Google, настройте эти инструменты прямо сейчас. У Apple это в Settings → Apple ID → Legacy Contact. У Google — в Account → Data & Privacy → More options → Make a plan for your account.

Шаг 6. Завещательное распоряжение в банке. Статья 1128 ГК. Бесплатно. Сходите в банк, где у вас вклад или большой остаток на счёте, и оформите распоряжение в пользу нужного человека. Это вытаскивает деньги из общей наследственной массы и ускоряет получение для конкретного наследника.

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

Шаг 8. Обновление раз в год. Раз в год пересматривайте всё перечисленное. Активы меняются — появляются новые аккаунты, исчезают старые, меняются пароли, добавляются криптокошельки. Один день в году на эту работу — окупается.

14. Финал: ответственность перед теми, кто останется

Тема цифрового наследства тяжёлая, потому что она заставляет думать о собственной смерти. Это неприятно. И поэтому подавляющее большинство людей этого не делает.

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

В российских условиях это особенно важно, потому что наша правовая и регуляторная инфраструктура цифрового наследства намного менее зрелая, чем американская или европейская. У Apple и Google есть формальные процедуры. У Яндекса и VK — формально только удаление, доступ к содержимому никто не отдаст. У Госуслуг — простая зомби-логика. КЭП передать невозможно. Криптовалютный кошелёк невозможно открыть без seed-фразы. Российский нотариус не оформит вам наследство на аккаунт ВКонтакте, даже если вы попросите.

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

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

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

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

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

Российское законодательство

Практическое

Инструменты при жизни

KeePassXC — открытый локальный менеджер паролей. Не требует подписки, не зависит от внешних сервисов; передачу доступа после смерти придётся настраивать вручную (банковская ячейка с мастер-паролем, копии файла-хранилища у доверенных людей, разделение пароля на части).
Google Inactive Account Manager — настройка для Google-аккаунта.
Apple Legacy Contact — официальный гид — настройка для Apple ID.
Стальные пластины для seed-фразы (общее название категории — «steel wallet», «crypto seed plate»). Оригинальные Cryptosteel и Billfodl из РФ официально не купить (производители — европейские компании, доставка/оплата затруднены санкциями), но на Ozon и Wildberries продаются десятки реплик за 1000–3000 ₽; либо можно сделать самостоятельно из стальной пластины и набора стальных штампов для металла. Назначение одно: пережить пожар и затопление, в отличие от бумаги.

Шнайер против Шнайера: история человека, который переписал свою главную книгу

2026-06-03T20:16:31.997Z

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

Брюс Шнайер последние тридцать с лишним лет, пожалуй, самый узнаваемый в мире голос в области информационной безопасности. Он автор десятка книг, ведёт ежемесячную рассылку с 1998 года и блог с 2004-го, каждый месяц комментирует все крупные инциденты и политические дискуссии вокруг приватности и безопасности, входит в советы EFF, Tor Project и Access Now, преподаёт публичную политику в Гарварде, выступает в Конгрессе США, давал интервью практически каждому большому медиа на планете. Если у этой ИБ есть главный представитель, то это Шнайер.

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

В 1994 году Шнайер выпустил книгу «Applied Cryptography» («Прикладная криптография») — учебник, который вытащил криптографию из академических журналов и засекреченных лабораторий и превратил в обычную инженерную практику. По этой книге выучилось несколько поколений разработчиков. Синяя и красная обложки её английских изданий стали узнаваемыми, как обложки кнутовского «The Art of Computer Programming». Книга задала ИБ-настроение девяностых: «у нас есть мощная математика, у нас есть проверенные алгоритмы, у нас есть открытые исходники — давайте просто правильно их применим, и всё будет защищено». Эту установку подхватила практически вся индустрия. И Шнайер стал настоящим законодателем мод.

Через шесть лет, в августе 2000 года, он публикует свою вторую большую книгу — «Secrets and Lies: Digital Security in a Networked World» («Секреты и ложь: цифровая безопасность в сетевом мире»). В её предисловии он делает невероятную для серьёзного эксперта в любой технической области вещь: признаёт, что в своей предыдущей фундаментальной книге он ошибся в самом важном — не в фактах и не в формулах, а в общей установке относительно собственного предмета.

Цитата из предисловия:

Ошибка Applied Cryptography в том, что я вообще не говорил о контексте. Я говорил о криптографии так, словно это и есть Ответ™. Я был довольно наивен.

И чуть дальше:

Если вы думаете, что технология решит ваши проблемы безопасности, значит, вы не понимаете ни проблем, ни технологии.

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

Этот пост — биография Шнайера и история его публичного разворота. Я расскажу, кто он такой, как Applied Cryptography в 1994-м стала культурным событием в индустрии, через какие практические истории Шнайер прошёл за следующие шесть лет, и почему именно в 2000 году он написал ту самую книгу, в которой переописал предмет своей жизни. Доберусь до его эссеистики, блога Schneier on Security, истории с документами Сноудена 2013 года, и до того, как его сегодняшние идеи о безопасности замыкаются на ту же установку, которую я описывал в недавнем посте про эпоху недоверия.

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

1. Кем он был до Applied Cryptography

Брюс Шнайер родился 15 января 1963 года в Нью-Йорке. Учился сначала на физика в Рочестерском университете (бакалавриат, 1984), потом перешёл в Американский университет в Вашингтоне на магистратуру по информатике (1988). То есть формального образования по криптографии у него никогда не было.

В конце 1980-х он работал в Министерстве обороны США, потом в Bell Labs, потом в различных коммерческих компаниях. В 1991 году его уволили. И как раз после этого началась его писательская карьера.

Сначала он писал статьи в компьютерные журналы — Dr. Dobb’s Journal, Macworld, Computer & Communications Security Reviews. Параллельно занимался криптографическим консалтингом через собственную консультационную фирму Counterpane Systems. Аудитория его статей была относительно узкой — программисты, которые хотели понять, как устроены практические алгоритмы шифрования. Профессиональное криптографическое сообщество в академическом смысле он обходил стороной: не публиковал работы на международных криптографических конференциях вроде CRYPTO или EUROCRYPT, не имел учёной степени уровня PhD (в западной академической традиции это высшая научная степень после защиты диссертации, аналог российского «кандидата наук»), не работал в университетских лабораториях.

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

К 1992 году у него накопилось достаточно материала, чтобы предложить издательству Wiley большую книгу. И он её написал.

2. Applied Cryptography (1994): революция в индустрии

Applied Cryptography: Protocols, Algorithms, and Source Code in C вышла в 1994 году в издательстве Wiley. Подзаголовок книги ясно говорит о её содержании: протоколы, алгоритмы и исходный код на C. Это был учебник для практиков.

Через два года, в октябре 1996-го, вышло второе издание — 758 страниц с красной обложкой (первое было синим). Это и есть то издание, которое стало настольной книгой для индустрии: оно содержало больше алгоритмов (включая блочные шифры, появившиеся к 1996-му), больше протоколов (в том числе свежий SSL), больше готового кода.

Что было в книге:

Блочные шифры: DES, IDEA, Blowfish (который сам Шнайер и придумал в 1993-м), RC4, RC5, разные модификации.

Хеш-функции: MD5, SHA-1, RIPEMD.

Асимметричная криптография: RSA, Diffie-Hellman, ElGamal, эллиптические кривые.

Протоколы: аутентификация, ключевой обмен, цифровые подписи, slot-нотация, протоколы голосования, протоколы анонимного доступа.

Исходный код: примеры реализации на C. Любой разработчик мог взять код из книги и встроить его в свой продукт.

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

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

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

Это был технооптимизм 1990-х в чистом виде. И его разделяли почти все, кто читал Applied Cryptography.

3. История с Филом Карном и экспортной дискетой

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

Инженер Фил Карн (Phil Karn) подал заявку в Государственный департамент США на разрешение экспортировать Applied Cryptography за рубеж. Госдеп выдал разрешение: книга — это печатное издание, защищённое Первой поправкой о свободе слова, экспортировать её можно.

Через некоторое время Карн подал вторую заявку: разрешить экспорт дискеты с тем же кодом, который уже напечатан в книге. Логика была проста: содержимое идентичное, только формат другой. Госдеп проконсультировался с АНБ (Агентство национальной безопасности), и в экспорте дискеты было отказано на том основании, что дискета — это «военная технология двойного назначения», и её экспорт регулируется International Traffic in Arms Regulations (ITAR).

То есть юридически Соединённые Штаты в 1996 году заявили: текст книги — это свободные слова, а тот же текст в виде кода на дискете — оружие.

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

В 1999 году Девятый окружной апелляционный суд по делу Bernstein v. United States окончательно постановил, что исходный код является защищённой Первой поправкой формой выражения. Это формально закрыло криптовойны. Экспортные ограничения на криптографию были сняты в 2000 году.

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

4. Что начало ломаться

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

Большая часть систем, которые ломали или которые имели уязвимости, были скомпрометированы не из-за слабых алгоритмов. Шифры работали. Математика была корректной. Однако системы всё равно проваливались — потому что:

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

То есть криптография работала, а безопасность — нет. Это два разных явления, которые Шнайер в Applied Cryptography смешал до неразличимости. Книга заявляла: если у тебя сильный шифр, у тебя сильная защита. А на практике оказалось, что сильный шифр — это меньше десяти процентов реальной защиты. Остальные девяносто — это процессы, люди, организации, интерфейсы, экономика, инциденты.

К 1998 году Шнайер начал писать об этом публично. Он запустил ежемесячную email-рассылку Crypto-Gram (с 1998 года, до сих пор выходит каждый месяц 15-го числа), в которой разбирал реальные случаи провала безопасности. И в этих разборах криптография фигурировала редко. Гораздо чаще речь шла об архитектурных ошибках, организационных провалах, человеческих факторах.

В августе 1999 года он основал компанию Counterpane Internet Security. Это была не консалтинговая фирма, а полноценный managed security services provider — компания, которая мониторила сети клиентов в реальном времени и реагировала на инциденты. И сам факт того, что главный криптограф мира создал компанию по мониторингу, а не по продаже сильных алгоритмов, говорил о многом.

5. Secrets and Lies (август 2000): публичное признание

К 2000 году Шнайер был готов написать книгу о том, что он понял за прошедшие шесть лет. И эта книга — Secrets and Lies: Digital Security in a Networked World — вышла в августе 2000 года, в том же издательстве Wiley.

В предисловии Шнайер разворачивает то самое признание, с которого мы начали этот пост, в подробное объяснение. Главный его упрёк к себе самому такой: в Applied Cryptography почти всё внимание ушло на математику и алгоритмы, и почти ничего — на людей, процессы, организации, ошибки реализации, ошибки пользователя. Алгоритмы из той книги, по его собственным словам, по-прежнему корректны и полезны, но если читать её как руководство к построению безопасной системы, она вводит в заблуждение. Безопасность складывается из всего того, что в Applied Cryptography осталось за скобками. И вторая знаменитая фраза, которую мы цитировали во вступлении, — про то, что «технологии не решат ваши проблемы безопасности», — это уже развёрнутое обоснование того же тезиса, под которое в книге подведены сотни страниц практических аргументов.

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

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

Безопасность — это цепь, прочность которой определяется самым слабым звеном. Самый сильный шифр не поможет, если ключи хранятся в файле config.ini с правами 777. Самый совершенный файрвол бесполезен, если у админа пароль 12345. Безопасность работает не локально, а по всей цепочке.

Модель угроз. Прежде чем что-то защищать, нужно понять, от кого и от чего. Защищаемся ли мы от государственного актора, от хакера-одиночки, от инсайдера, от случайного ошибочного действия? Каждая модель угроз требует своих мер. Универсальной «защиты» нет.

Дерево атаки. Формальная методика моделирования атак, которую Шнайер представил ещё в декабре 1999-го в статье в Dr. Dobb’s Journal. Дерево атаки: корень — цель атакующего, узлы — способы её достижения, листья — конкретные действия. Такая структура помогает увидеть, какие пути доступны атакующему, и систематически защищаться от них.

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

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

Это всё в Applied Cryptography полностью отсутствовало. И Шнайер прямо это признал.

6. Реакция: не скандал, а взросление

Что важно: разворот Шнайера в Secrets and Lies не вызвал скандала. Никто не обвинял его в предательстве. Никто не разбирал предисловие как «капитуляцию».

Наоборот, индустрия приняла Secrets and Lies как долгожданное взросление. Потому что к 2000 году многие практикующие специалисты уже пришли к тому же выводу, что и Шнайер, но не имели слов или решимости, чтобы это сформулировать. У них был ежедневный опыт, но не было концептуального аппарата. Шнайер дал им этот аппарат.

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

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

7. Эпоха блога и эссеистики

После Secrets and Lies Шнайер всё больше превращается из технического эксперта в публичного интеллектуала. В октябре 2004 года он запускает блог Schneier on Security параллельно с продолжающейся рассылкой Crypto-Gram. К 2026 году суммарная аудитория двух каналов перевалила за 250 тысяч читателей.

Каждый день он разбирает там свежие инциденты и уязвимости, технические новости, политические сюжеты вокруг приватности и слежки, странные случаи из мира физической безопасности (особенно много — про авиаперевозки, охрану аэропортов и американскую TSA — Transportation Security Administration, ведомство, которое отвечает за досмотр пассажиров в США; примерно как российский «АТБ» — авиационно-транспортная безопасность, но с гораздо большим публичным весом и собственным бюджетом). Параллельно с разбором текущей повестки в этих заметках постепенно сформировались несколько концепций, которые вошли в общее интеллектуальное наследие отрасли.

Термин «театр безопасности» Шнайер придумал в книге Beyond Fear (2003). Это меры безопасности, которые создают ложное чувство защищённости, не давая реальной защиты. Самый яркий пример — TSA в американских аэропортах: длинные очереди, ритуальное снятие обуви, изъятие шампуней — всё это даёт пассажирам ощущение, что «что-то делается», но не предотвращает ни одной реальной террористической атаки (что подтверждено независимыми аудитами TSA — её собственные тесты обнаружили уязвимости в 95% случаев). Шнайер потратил годы на критику TSA как самого яркого примера security theater, и постепенно термин ушёл в массовое использование.

«Угрозы из киносценария» — это страхи, которые звучат драматично, но статистически крайне маловероятны. «А что если террорист сделает вот это конкретное?» — а ответ всегда: вероятность ничтожна, разумнее защищаться от более частых угроз. В 2005–2006 годах Шнайер устраивал в блоге конкурсы на самые абсурдные movie-plot threats, чтобы показать, что воображение порождает бесконечное количество таких сценариев, и защищаться от каждого по отдельности невозможно.

Schneier’s Law. Эта формулировка интересна сама по себе. В эссе 1998 года «Memo to the Amateur Cipher Designer» Шнайер писал:

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

Это не было оформлено как «закон». Название Schneier’s Law придумал и закрепил Кори Доктороу в 2004 году. То есть это не самопровозглашённый закон, а формулировка, которую сообщество подобрало и присвоило автору. Сам Шнайер потом её разъяснил: суть в том, что умение сломать собственное произведение требует другого мышления, и пока несколько разных умов не попытаются взломать ваш шифр, не имеет смысла говорить о его стойкости. Поэтому открытость — это не уязвимость, а обязательное условие настоящей криптографической работы.

8. Новые книги

После Secrets and Lies Шнайер продолжает писать книги, и каждая расширяет тему дальше. Не «как защитить ваш сервер», а «как устроена безопасность в обществе и в технологии в целом».

Beyond Fear («По ту сторону страха»), 2003. Безопасность как общесоциальное явление. Анализ страхов, рисков, рациональности. Эта книга — фундаментальный текст для понимания того, почему мы делаем плохие выборы в области безопасности: мы переоцениваем редкие драматичные угрозы и недооцениваем повседневные, привычные.

Liars and Outliers («Лжецы и исключения»), 2012. О доверии в обществе. Шнайер исследует, как именно общество создаёт условия для сотрудничества — через социальные нормы, законы, репутационные механизмы, технологические системы. Это книга больше про социологию, чем про технологию, но именно через неё Шнайер расширяет понятие «безопасность» до общесоциальной категории.

Data and Goliath («Данные и Голиаф», игра слов на «Давид и Голиаф»), 2015. О слежке. Книга вышла после разоблачений Сноудена и стала одним из главных публичных текстов на эту тему. Шнайер показал, что массовая слежка — это не только государство, а целая экономика данных, в которую вовлечены технологические компании, рекламные сети, страховые компании, банки. Подзаголовок книги — «The Hidden Battles to Collect Your Data and Control Your World» («Скрытые войны за ваши данные и контроль над вашим миром»).

Click Here to Kill Everybody («Нажмите здесь, чтобы убить всех»), 2018. О безопасности интернета вещей. Когда подключёнными становятся не серверы, а автомобили, дома, медицинские устройства — провалы безопасности перестают быть банальной утечкой данных и становятся угрозой жизни. Шнайер на конкретных примерах показывает, что мы строим IoT без учёта безопасности, и это закончится катастрофой.

A Hacker’s Mind («Мышление хакера»), 2023. О мышлении хакера как универсальной интеллектуальной установке. Хакерство — это поиск уязвимостей в правилах, и эта установка применима не только к коду, но и к налоговому законодательству, выборным системам, финансовым продуктам, общественным институтам.

Rewiring Democracy («Перенастройка демократии»), с Натаном Сандерсом, 2025. О том, как ИИ и цифровые технологии меняют демократические институты.

Шесть больших книг после Applied Cryptography. Каждая дальше от чистой криптографии и ближе к общему пониманию того, как устроены сложные сложно-социотехнические системы.

9. 2013: Шнайер и документы Сноудена

Летом 2013 года в Гонконге Эдвард Сноуден передал журналистам Glenn Greenwald и Laura Poitras огромный архив секретных документов АНБ. Через несколько недель Greenwald связался с Шнайером и пригласил его в Рио-де-Жанейро, где работала команда The Guardian. Шнайер читал документы и помогал журналистам разбираться в технической стороне программы массовой слежки АНБ.

В сентябре 2013-го он опубликовал в Guardian статью «NSA Surveillance: A Guide to Staying Secure» — практическое руководство по защите от государственной слежки. И в той же статье он сделал, наверное, самое точное наблюдение о случившемся:

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

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

Это, по сути, повторение тезиса Secrets and Lies в новом контексте. И сама ситуация со Сноуденом стала для Шнайера ещё одним подтверждением: криптография — это не синоним безопасности. Безопасность включает в себя криптографию, но это гораздо более широкое понятие.

После 2013 года Шнайер становится одним из главных публичных голосов критики массовой слежки. Он публикует Data and Goliath. Он выступает в Конгрессе США. Он входит в советы EFF, Access Now, Tor Project. Его позиция остаётся той же: технологии — это инструменты, и их безопасное использование зависит от политических и социальных условий, а не от качества самих технологий.

10. Где Шнайер сейчас

В 2026 году Шнайеру исполнилось 63 года, и он остаётся одной из самых заметных фигур в сфере безопасности.

Его текущие позиции:

внештатный преподаватель в Гарвардской школе Кеннеди (Harvard Kennedy School), где ведёт курсы по государственной политике в области технологий и безопасности;
научный сотрудник Беркмановско-Кляйновского центра по изучению интернета и общества при Гарвардском университете (с 2013 года);
главный архитектор по безопасности в компании Inrupt, которую основал Тим Бернерс-Ли и которая развивает протокол децентрализованного веба Solid;
член советов Electronic Frontier Foundation (EFF), Access Now, Tor Project.

Его компания Counterpane Internet Security была куплена British Telecom 25 октября 2006 года (сумма не разглашалась). С 2016 по 2019 год Шнайер работал в IBM, куда попал после покупки IBM компании Resilient Systems, советником которой он был. После 2019-го больше фокусируется на академической и публицистической работе.

Награды и признание:

Награда «Пионер» от Electronic Frontier Foundation (Фонд электронных рубежей), 2007;
Премия имени Норберта Винера от ассоциации Computer Professionals for Social Responsibility («Программисты за общественную ответственность»), 2008;
Почётная докторская степень Вестминстерского университета (University of Westminster), 2011;
Награда за вклад в защиту приватности от Electronic Privacy Information Center (EPIC), 2015.

Тьюринговскую премию Шнайер не получал — это не совсем его профиль. Тьюринговку дают за фундаментальные вклады в теорию вычислений или системную архитектуру, а Шнайер — публичный ИБ-интеллектуал, а не академический исследователь. Но его влияние на индустрию вряд ли уступает многим лауреатам Тьюринга.

11. Что значит этот разворот

Шнайер прошёл редкий путь: от создателя главной книги о криптографии до публичного критика собственной книги и публичного ИБ-интеллектуала.

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

Почему так? Я думаю, по нескольким причинам.

Первая. Разворот был тонко артикулирован. Шнайер не сказал «Applied Cryptography была неправильная книга, выбросьте её». Он сказал «эта книга была неполная, в ней не хватало контекста». Информация в книге не отменялась, она дополнялась. Это совсем другой эпистемологический жест: не отказ от прошлого, а расширение взгляда.

Вторая. Разворот пришёлся на время, когда индустрия созрела для этого. Если бы Шнайер написал Secrets and Lies в 1995-м, его бы не поняли. К 2000-му многие практики уже жили в той же реальности — крипто работает, безопасность не работает. Им нужны были слова, и Шнайер их дал.

Третья. Шнайер подтвердил свою новую позицию делами. Он основал Counterpane Internet Security ещё до выхода Secrets and Lies. Он писал ежемесячные эссе про реальные инциденты, в которых криптография почти не играла роли. То есть его слова про «безопасность — это процесс» не были декларацией, а результатом многолетних практических наблюдений.

Четвёртая. И, наверное, самая важная: Шнайер всё это время оставался полезен индустрии. Если бы после Secrets and Lies он начал просто критиковать всё подряд, никому бы не помогая, его быстро бы списали как «бывшего эксперта». Но он продолжал давать конкретные рекомендации, разбирать конкретные инциденты, формулировать конкретные методики (attack trees, threat models). Его авторитет держался не на статусе, а на постоянной генерации практической пользы.

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

12. Финал: чему стоит учиться у Шнайера

Тезис Secrets and Lies — что криптография не равна безопасности — давно вошёл в учебники и звучит на каждой второй конференции по ИБ. На уровне идей про защиту это уже аксиома. Но главный урок Шнайера, как мне кажется, вообще не в этом.

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

И это, как ни парадоксально, окупилось. Технологический ландшафт за тридцать лет успел поменяться несколько раз, и эксперт, зафиксировавший свою позицию в 2000-м, к 2026 году обычно говорит глупости. А Шнайер по-прежнему читается, цитируется, приглашается в Конгресс и Гарвард — потому что его позиции эволюционировали вместе с предметом. Каждое следующее «я думаю иначе, чем десять лет назад, и вот почему» только укрепляло его авторитет.

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

Главные книги

Applied Cryptography (1994, второе издание 1996) — справочник, который определил эпоху. Русское издание: «Прикладная криптография. Протоколы, алгоритмы и исходные тексты на языке Си» (издательство «Триумф», переиздаётся с 2002 года). Оригинальная страница на сайте автора.
Secrets and Lies (2000) — публичный разворот, изменивший индустрию. Русское издание: «Секреты и ложь. Безопасность данных в цифровом мире» (издательство «Питер», 2003). Полное предисловие и страница на сайте автора — на английском.
Beyond Fear (2003) — безопасность как общесоциальное явление. На русский не переводилась; англоязычная страница на сайте автора.
Liars and Outliers (2012) — о доверии в обществе. На русский не переводилась; англоязычная страница.
Data and Goliath (2015) — о массовой слежке. На русский не переводилась; англоязычная страница.
Click Here to Kill Everybody (2018) — о безопасности интернета вещей. На русский не переводилась; англоязычная страница.
A Hacker’s Mind (2023) — о хакерском мышлении как универсальной интеллектуальной установке. На русский не переводилась; англоязычная страница.

Эссе и тексты

«NSA Surveillance: A Guide to Staying Secure», The Guardian, 6 сентября 2013 — практический гид после Сноудена.
«Attack Trees», Dr. Dobb’s Journal, декабрь 1999 — каноническая статья.
«The Future of Crypto-Gram» — Шнайер о десятилетней истории своей рассылки.

Регулярно обновляемое

Schneier on Security — главный блог, с октября 2004.
Crypto-Gram — ежемесячная email-рассылка, с 1998 года.

Биографическое

Bruce Schneier — Wikipedia — самая подробная биография.
Биографическая страница на schneier.com.

Эпоха недоверия: почему я хочу переписать всё под себя

2026-06-02T18:38:34.909Z

У меня лежит на столе пустой SSD-диск. Я давно собираюсь поставить на него OpenBSD — операционную систему, у которой главным дизайнерским решением последние тридцать лет является безопасность. Поставить, добавить графическое окружение Xfce, перенести туда работу с текстами, программирование, лёгкую обработку картинок. Это не философский жест, а вполне практический план: машина, на которой я держу свои тексты и код, не должна за мной следить, и не должна быть проницаема для тех, кто не я.

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

Этот пост — попытка разобраться, что именно в среде изменилось, и почему именно к 2026 году недоверие к цифровым сервисам стало не маргинальной позицией, а вполне распространённой инженерной установкой. Я разберу, что делают «бесплатные» сервисы, как устроены современные мобильные приложения, какие истории случились с «защищёнными» мессенджерами и почтой. Доберусь до уровня операционной системы. Покажу, насколько хрупкой стала цепочка поставок программного обеспечения — на примере истории xz-utils в марте 2024-го, после которой стало понятно, что чистый код вашего проекта не имеет значения, если зависимости скомпрометированы. И в финале — серьёзный разбор того, что значит возвращение контроля в реальном мире: где это реально работает, где это утопия, и почему OpenBSD для меня сегодня не философское заявление, а конкретный план.

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

1. Что именно изменилось

Я не могу назвать конкретную дату, после которой моё отношение к цифровой среде стало другим. Но я могу описать переворот, который произошёл за последние десять-пятнадцать лет.

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

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

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

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

2. «Бесплатные» сервисы и экономика данных

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

Если вы не платите за продукт — продукт это вы.

Эта формулировка слегка упрощённая (бывают исключения вроде Wikipedia или некоторых open-source проектов), но она схватывает главное: большинство «бесплатных» цифровых сервисов содержат себя за счёт того, что собирают данные о пользователях и монетизируют их, обычно через таргетированную рекламу.

Gmail — это рекламная компания, которая даёт людям почту. Её материнская компания Alphabet в 2024 году получила более 80% выручки от рекламы. Когда вы пишете в Gmail письмо, оно сканируется (да, не «читается человеком», но машинная обработка идёт), индексируется, используется для построения вашего профиля интересов. Когда вы открываете Google Maps и ищете кафе, это становится сигналом «пользователь интересуется ресторанами в этом районе». Когда вы смотрите YouTube, это сигналы о ваших вкусах, политических взглядах, эмоциональном состоянии в данный момент.

Каждый отдельный сигнал ничего не значит. Но в сумме они дают очень точный портрет конкретного человека. И этот портрет — товар, который Google продаёт рекламодателям. Это легально, это описано в условиях использования, которые вы приняли при создании аккаунта. Просто условия эти никто никогда не читает.

Похожая логика у Facebook, Instagram (принадлежат компании Meta, признанной в РФ экстремистской организацией; её деятельность запрещена), TikTok, LinkedIn. У Twitter/X, Discord, Reddit. У всех «бесплатных» сервисов социального плана, и у большинства коммерческих сервисов с бесплатным тарифом.

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

3. Мобильные приложения: гонка следящих модулей

Мобильные приложения собирают данные глубже, чем сайты — там, где у браузера хотя бы есть встроенные ограничения (песочница вкладки, блокировщики, политика cookies), у нативного приложения их почти нет. Современное приложение для смартфона практически всегда содержит несколько встроенных пакетов аналитики, которые называются красивыми именами вроде Facebook SDK, AppsFlyer, Adjust, Mixpanel, Amplitude, Sentry, Firebase Analytics, Branch. Каждый из этих пакетов собирает свой набор данных и отправляет их на серверы своей компании.

Что они собирают? В типичном случае:

идентификатор устройства (рекламный ID, который должен быть «анонимным», но прекрасно сопоставляется с конкретным человеком);
модель устройства, версия операционной системы, языковые настройки;
адрес IP и приблизительная геолокация;
какие экраны вы открывали в приложении, в каком порядке, как долго на каждом задерживались;
какие кнопки нажимали;
сколько секунд провели в приложении, в какое время суток, как часто запускаете;
иногда — что вы вводили в текстовых полях (не пароли, как правило, но другой текст);
иногда — список других установленных приложений на вашем устройстве.

Эти данные сводятся в один профиль, общий для разных приложений. Если вы открыли утром приложение банка, потом приложение службы доставки, потом мессенджер, все три, скорее всего, отправили свои наблюдения за вашим поведением на одни и те же серверы, потому что у всех трёх стоит, например, Facebook SDK или Google Analytics. На стороне этих серверов данные от разных приложений склеиваются по общему идентификатору устройства и получается единая картина того, чем вы занимались утром, где находились и какие интересы у вас за день проявились. Через несколько дней такой работы ваш профиль становится очень точным.

Побочный эффект — мобильные приложения раздулись до сотен мегабайт. Простой мессенджер сегодня может занимать 250–400 мегабайт, потому что в нём, кроме собственно мессенджера, лежат библиотеки аналитики от пяти-семи разных компаний, библиотеки A/B-тестирования, библиотеки таргетинга рекламы, распознавания шрифтов, графики, изображений. Когда пользователи жалуются, что современные приложения тормозят даже на новых телефонах, основная причина именно здесь: процессор и память расходуются не на ваши задачи, а на работу всех этих паразитных модулей в фоне. Полезный код тонет в следящей инфраструктуре.

В Apple с 2021 года введена политика App Tracking Transparency, которая требует у пользователя явного разрешения на сбор межприложенческих данных. Это сильно ударило по Facebook (в 2022 году Meta объявила, что эта политика стоила им 10 миллиардов долларов США годовой выручки). Но это не остановило сбор данных внутри приложения, между приложениями одной компании, и для серверной аналитики, всего лишь немного его ограничило.

На Android ситуация хуже: у Google есть свой аналог App Tracking Transparency — Privacy Sandbox для Android, — но он слабее по требованиям к разработчикам, и общая культура сбора данных в экосистеме гораздо более вольная.

4. Мессенджеры

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

Signal — почти единственный в массовом сегменте, к которому я отношусь с реальным уважением. Шифрование сквозное и прозрачное (Signal Protocol — открытый стандарт, который скопировали WhatsApp и Facebook Messenger). Серверы держат минимум метаданных (Signal в 2016 году публиковала, что в ответ на повестку федерального суда они смогли предоставить только дату создания аккаунта и дату последнего подключения — больше у них реально не было). Финансируется некоммерческим Signal Foundation, без рекламы. Исходный код открыт. Это, наверное, лучшее, что у нас есть для приватной переписки в массовом сегменте. В РФ он заблокирован как раз из-за того, что переписки в нём недоступны для прочтения третьими лицами, а это противоречит требованиями закона об ОРИ.

SimpleX — отдельная история, которая заслуживает упоминания именно в этом контексте. У всех остальных мессенджеров (включая Signal) есть фундаментальная общая черта: они знают, кто вы. Signal привязан к номеру телефона. Telegram тоже. WhatsApp — тем более. Даже если содержимое переписки они не видят, факт самого вашего существования как пользователя у них зафиксирован. У SimpleX этого нет — он сознательно отказался от любых идентификаторов пользователя. Сервер не знает, какие пользователи к нему подключены, потому что пользователей как объектов в его модели данных просто не существует. Это переизобретение модели приватности на уровне архитектуры протокола, и я уже разбирал его в отдельном посте. Если для вас приватность важнее удобства, SimpleX сегодня — главная альтернатива Signal.

WhatsApp использует тот же Signal Protocol для шифрования содержимого, но Meta собирает огромное количество метаданных: с кем вы переписываетесь, как часто, в какое время, какие группы. Метаданные часто говорят больше, чем содержимое. Метаданные интегрируются в общий профиль Meta вместе с данными из Instagram и Facebook.

Telegram — отдельная история. Шифрование сквозное только в «секретных чатах», которые по умолчанию выключены. Обычные чаты шифруются только между клиентом и сервером — то есть Telegram-серверы видят содержимое. У Telegram сложная история с регуляторами (он отказывался выдавать данные ФСБ в 2017–2018, потом его пытались блокировать в России, потом разблокировали, потом репутация менялась туда-сюда). Внутри компании прошли реорганизации. После ареста Павла Дурова во Франции в августе 2024-го (по обвинениям в недостаточном сотрудничестве с правоохранительными органами в делах, не связанных с приватностью) Telegram объявил, что начнёт выдавать данные пользователей по законным запросам.

iMessage — шифрование сквозное, но Apple по умолчанию делает бэкап вашей переписки в iCloud, и этот бэкап Apple может расшифровать, если у вас не включена Advanced Data Protection (она введена в 2022 году, по умолчанию выключена, и большинство пользователей о ней даже не знают). То есть формально iMessage защищён, на практике — обычно нет.

WeChat, Line, KakaoTalk — национальные мессенджеры, для которых сотрудничество с местными властями встроено в саму архитектуру. О них я говорить не буду, потому что их пользователи обычно сознательно принимают эти правила.

Примечание. Понятие организатора распространения информации (ОРИ) ввёл в российское законодательство Федеральный закон №97-ФЗ от 5 мая 2014 года: он добавил статью 10.1 в базовый Закон об информации №149-ФЗ от 27 июля 2006 года. Обязанность хранить содержимое переписки за шесть месяцев и метаданных за год, а также предоставлять ФСБ ключи для расшифровки содержимого, появилась в так называемом «пакете Яровой» — Федеральные законы №374-ФЗ и №375-ФЗ от 6 июля 2016 года, основные положения которых вступили в силу 1 июля 2018 года. С этого момента любой сервис, через который пользователи обмениваются сообщениями, обязан регистрироваться в Роскомнадзоре и обеспечивать выдачу содержимого по требованию ФСБ. Сервисы, у которых сквозное шифрование настоящее (то есть ключи существуют только у пользователей и физически не могут быть переданы третьей стороне), это требование исполнить не могут.

Именно поэтому в РФ заблокированы Signal и SimpleX — оба сервиса по архитектуре не способны передать содержимое переписок, потому что ключей для расшифровки переписок у них нет. Голосовые и видеозвонки WhatsApp Роскомнадзор заблокировал в августе 2025 года, а 11 февраля 2026 года домены whatsapp.com и web.whatsapp.com исключили из Национальной системы доменных имён (НСДИ) — обязательной DNS-инфраструктуры всех российских провайдеров. С этого момента WhatsApp в РФ доступен только через VPN или сторонние DNS-резолверы.

Telegram блокировали в 2018–2020-м, потом разблокировали (де-факто за счёт договорённостей, о деталях которых открытой информации нет). А 10 февраля 2026 года Роскомнадзор официально признал, что снова замедляет его работу — через систему ТСПУ (технических средств противодействия угрозам) на основе глубокой инспекции пакетов (DPI). К середине марта 2026-го доля неуспешных запросов к серверам Telegram из России выросла примерно до 80%, у пользователей перестали грузиться медиа, потом и текстовые сообщения. 23 марта Госдума приняла закон, позволяющий Роскомнадзору самостоятельно блокировать трафик через ТСПУ, без участия провайдеров. К началу апреля 2026-го объявлено о полной блокировке.

Таким образом, в РФ требования закона прямо противоположны тому, что для пользователя означает «приватный мессенджер»: чем приватнее сервис, тем выше шанс, что им станет нельзя пользоваться без спецсредств.

В итоге картина такая: если вам важна приватность переписки, у вас по сути два реалистичных выбора — Signal для массовой связи и SimpleX для самых чувствительных разговоров. Но следует иметь в виду, что без трехбуквенного заклинания они не работают. Ну а все остальные мессенджеры, которые работают в РФ, не обеспечивают приватность ни в каком виде. Ваши переписки могут читать. Личные тоже. Просто имейте это в виду, когда соберётесь высказаться откровенно в переписке с другом.

5. «Защищённая» почта и судебные запросы

С почтой история ещё интереснее. Сервисы вроде ProtonMail и Tutanota продают себя как «защищённую» почту с серверами в Швейцарии и Германии, со сквозным шифрованием, со слоганами вроде «мы не можем прочитать ваши сообщения». И это правда, но только частично.

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

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

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

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

Похожая история была у Tutanota (теперь Tuta Mail) с немецкими судами в 2020–2021 годах: им предписывали мониторить новые входящие письма для конкретных аккаунтов в реальном времени. Tutanota подчинилась.

Ещё более показательный случай — Hushmail в 2007 году. Канадский «защищённый» почтовый сервис передал расшифрованные сообщения американскому DEA по запросу через канадские суды. Hushmail тогда честно объяснил: их «сквозное шифрование» происходило в Java-апплете на стороне клиента, и при необходимости они могли подменить апплет так, чтобы он передал пароль пользователя на сервер. Технически это была идеальная схема для соблюдения закона при сохранении маркетингового заявления о безопасности.

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

6. Облачные хранилища

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

Google Drive, Microsoft OneDrive, Apple iCloud, Dropbox, Yandex.Disk — все эти сервисы хранят ваши файлы на своих серверах в незашифрованном для них виде (или в виде, который сервис может расшифровать). Это значит, что технически сервис может:

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

Несколько ярких случаев последних лет.

Apple CSAM Detection (август 2021). Apple объявила о технологии, которая будет автоматически сканировать фотографии пользователей в iCloud Photos на предмет соответствия известным образцам жестокого обращения с детьми (CSAM). Технология использовала нейросетевые отпечатки и должна была работать «на устройстве» с отправкой только подозрительных совпадений. Цель — благородная. Но криптографическое сообщество и правозащитники объяснили: технология создаёт инфраструктуру для любого сканирования данных пользователей. Если эта технология есть, никто не помешает её расширить на другие категории контента, включая политически чувствительные. Под давлением Apple отказался от запуска CSAM-сканирования в декабре 2022 года.

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

Adobe и обновление условий использования (июнь 2024). Adobe в феврале 2024 года обновил условия использования своих сервисов (Creative Cloud), добавив пункт, который сообщество интерпретировало как разрешение использовать содержимое пользователей для тренировки моделей машинного обучения. Это вызвало взрыв в сообществе художников, фотографов, дизайнеров: люди, которые годами использовали Photoshop и Lightroom для коммерческой работы, обнаружили, что их собственные изображения могут быть использованы как тренировочный материал для конкурирующих ИИ-моделей. Adobe потом частично переписал условия, добавил исключения, объяснял, что не использует материалы для тренировки, но осадок остался.

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

нд) делает скриншот всего экрана и сохраняет его, чтобы потом можно было «найти всё, что вы делали на компьютере» через поиск. Анонс вызвал немедленный взрыв в сообществе безопасности: исследователи показали, что в первоначальной реализации база данных скриншотов лежала в открытом виде, доступна локально без шифрования, и любая программа на компьютере (включая вредоносную) могла её прочитать. Microsoft отложил релиз, переписал реализацию с использованием Windows Hello и шифрованием, потом снова отложил. К началу 2026 года Recall существует, но включается явно. Сам факт, что Microsoft серьёзно рассматривал такую функцию по умолчанию, — это новая глава в отношении операционной системы к пользователю.

macOS ведёт себя более сдержанно, но тоже отправляет зн## 7. Уровень операционной системы

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

Windows 11 собирает значительный объём телеметрии по умолчанию. Microsoft публично описывает её как «технические сведения» — типа какие функции используются, как часто падают приложения. На практике объём данных намного больше, чем нужно для диагностики. Существуют отдельные инструменты (O&O ShutUp10++ и подобные), помогающие отключить максимальное количество телеметрии. Сам факт того, что для отключения нужны отдельные инструменты, говорит о многом.

В мае 2024 года Microsoft анонсировала Windows Recall — функцию, которая периодически (каждые несколько секуачительный объём данных в Apple. С каждой версией добавляются новые ИИ-функции (Apple Intelligence в macOS 15), которые по умолчанию используют облачные серверы Apple для обработки запросов. Apple клянётся, что приватность сохраняется через Private Cloud Compute. Технически это, возможно, правда. Но по сути это означает, что я больше не понимаю, какие именно мои данные уходят в Apple-инфраструктуру.

Android в стандартных сборках от Google (на устройствах с Google Play) собирает огромный объём данных как через Google Services, так и через приложения, в которые встроены аналитические библиотеки. Альтернативные сборки (GrapheneOS, CalyxOS, LineageOS без G-Apps) существуют, но они требуют специфических устройств и серьёзной возни. Я в итоге купил себе Google Pixel и установил туда GrapheneOS вместо оригинальной гугловской системы — про устройство этой ОС, её модель угроз и реальный опыт перехода я уже подробно писал в двух отдельных постах.

ChromeOS — это, наверное, самый чистый случай. Это операционная система, которая дизайнерски является продолжением Google в форме железа. Если вы готовы к тому, что Google знает о вас всё, это нормальный выбор. Если нет — это не для вас.

И вот в этом контексте начинают становиться интересными альтернативы. Linux (особенно дистрибутивы вроде Debian, Fedora, Arch без проприетарных компонентов) — реальная и работающая альтернатива. Большинство Linux-дистрибутивов не собирают никакой телеметрии. Большинство Linux-приложений (текстовых редакторов, IDE, мессенджеров) — open source и не отправляют куда-либо данные о вашем использовании. Это не идеально (Linux-сообщество тоже не безгрешно), но это качественно другая ситуация.

А OpenBSD — это вообще отдельный разговор, к которому я ещё вернусь.

8. Цепочка поставок: история xz-utils

А теперь самая драматичная часть. До сих пор мы говорили о том, что коммерческие сервисы собирают данные. Но есть категория проблемы, которая страшнее: что если код, на котором работает вся ваша инфраструктура, скомпрометирован?

Современное программное обеспечение — это гигантский клубок зависимостей. Простая Node.js-программа из десяти строк может тащить за собой сотни npm-пакетов, написанных разными людьми в разных странах. Linux-дистрибутив включает тысячи пакетов, поддерживаемых разными мейнтейнерами. Python-приложение использует десятки PyPI-библиотек. И каждая из этих зависимостей — потенциальная точка атаки.

В 2024 году произошла история, которая стала самым ярким примером в истории open source. Называется она xz-utils backdoor, или CVE-2024-3094.

xz-utils — это набор утилит сжатия данных, используемый практически во всех Linux-системах. Не самая известная библиотека, но критическая часть инфраструктуры. С 2009 года её поддерживал финский разработчик Ларс Коллин (Lasse Collin), один человек, в свободное от работы время.

В 2021 году в проект пришёл новый контрибьютор под именем Jia Tan. Он начал с обычных полезных правок: исправления багов, улучшения производительности, доработок документации. Постепенно завоёвывал доверие. В то же время в проекте появлялись жалобы от других «пользователей» (как теперь подозревают, фейковых), что Коллин не успевает поддерживать проект, что нужны новые мейнтейнеры. Коллин, действительно перегруженный, постепенно передавал больше прав Jia Tan. К началу 2024 года Jia Tan фактически стал основным мейнтейнером.

29 февраля 2024 года был выпущен релиз xz-utils 5.6.0, а 9 марта — 5.6.1. В этих релизах был тщательно спрятанный бэкдор. Он не присутствовал в исходном коде, а был зашит в тестовые файлы (специально сконструированные «битые» архивы). Во время сборки специальный скрипт извлекал из них вредоносный код и встраивал его в библиотеку. Бэкдор активировался при подключении по SSH и позволял удалённому атакующему, знающему правильный ключ, выполнить любой код на скомпрометированной системе.

Если бы релиз 5.6.1 успел попасть в стабильные ветки Debian, Ubuntu, Red Hat, это была бы, наверное, крупнейшая компрометация интернет-инфраструктуры в истории. Огромная часть мировых SSH-серверов оказалась бы в распоряжении неизвестного злоумышленника.

Бэкдор обнаружил Андрес Фройнд — инженер Microsoft, занимающийся PostgreSQL. 29 марта 2024 года он отлаживал странность: его тестовый SSH-сервер подключался на полсекунды медленнее обычного. Полсекунды — крошечная задержка. Большинство людей её бы не заметили. Фройнд заметил, начал копать, и обнаружил замаскированный бэкдор. Через несколько часов он опубликовал предупреждение на список рассылки oss-security. К утру 30 марта весь мир уже знал о проблеме. Дистрибутивы откатили обновления. Атака провалилась.

Эта история — поучительная по нескольким причинам.

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

Во-вторых, атаку остановила счастливая случайность. Если бы Фройнд не отлаживал PostgreSQL именно в этот момент, если бы он не был достаточно внимателен, бэкдор попал бы в стабильные системы. Это означает, что другие подобные атаки могут уже идти прямо сейчас, просто мы о них не знаем и не сможем узнать, пока ещё одна счастливая случайность не вскроет ещё один заранее спланированный бэкдор.

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

Это и есть xkcd 2347 «Dependency» — знаменитый комикс Рэндалла Манро, который вышел в августе 2020 года. На рисунке огромная нестабильная башня под названием «Вся современная цифровая инфраструктура» опирается на маленький блок в самом основании: «Случайный проект, который один человек в Небраске поддерживает без оплаты с 2003 года». После истории с xz в 2024 году эта картинка перестала быть смешной — она оказалась буквально документальной.

xkcd 2347, Рэндалл Манро, август 2020. Источник: xkcd.com/2347, лицензия CC BY-NC 2.5.

9. Другие случаи цепочки поставок

xz — самый яркий, но не первый и не последний случай.

event-stream (npm, ноябрь 2018). Популярный npm-пакет с миллионами скачиваний в неделю. Его автор Доминик Тарр перестал активно поддерживать проект и передал права новому контрибьютору, который предложил помощь. Новый контрибьютор за несколько месяцев заслужил доверие и в одном из релизов добавил зависимость от другого пакета, который содержал вредоносный код. Цель — кража биткоин-кошельков из конкретного приложения Copay. Это был один из первых громких случаев атаки на npm.

Log4Shell (декабрь 2021, CVE-2021-44228). Уязвимость в Log4j — Java-библиотеке логирования, используемой в миллионах корпоративных приложений. Это не было атакой через цепочку поставок (бэкдора там не было, просто опасная функция, которую можно эксплуатировать), но эффект тот же: одна библиотека была повсюду, уязвимость была критической, обновление потребовалось срочно во всём мире. CISA называла это «одной из самых серьёзных уязвимостей в истории».

SolarWinds (декабрь 2020). Государственная атака (приписывают группе APT29 / Cozy Bear, российской SVR), скомпрометировавшая систему сборки SolarWinds Orion — корпоративного инструмента мониторинга сети. Около 18 тысяч организаций установили скомпрометированное обновление, включая правительственные ведомства США, Microsoft, FireEye. Это, наверное, самый громкий случай атаки на цепочку поставок в истории корпоративного программного обеспечения.

Polyfill.io (июнь 2024). Сервис, который автоматически подгружал миллионам сайтов полифилы — небольшие JavaScript-вставки, которые «дозаполняют» старые браузеры до поддержки новых веб-функций (например, объясняют браузеру, что такое Promise или fetch, если он этого ещё не знает). Название идёт от британской торговой марки шпаклёвки Polyfilla: идея в том, что библиотечка «заделывает дыру» в возможностях браузера. Так вот, в феврале 2024 года polyfill.io был куплен китайской компанией. Через несколько месяцев новый владелец начал внедрять вредоносный код в скрипты, отдаваемые с CDN. Cloudflare и другие провайдеры заблокировали polyfill.io, но многие сайты успели пострадать.

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

И это меняет инженерную дисциплину. Раньше «безопасный код» означал «отсутствие SQL-инъекций, переполнений буфера, XSS». Теперь это означает ещё и «контроль над всеми зависимостями, понимание, кто их поддерживает, отслеживание, кто получил права коммита». А когда у вас в проекте триста npm-пакетов, тысяча транзитивных зависимостей, — это становится физически невозможно для одной команды.

10. ИИ как новый агент сбора данных

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

Здесь я хочу подсветить один конкретный аспект — что происходит с данными, которые вы скармливаете ИИ-моделям.

GitHub Copilot. Когда вы пишете код с Copilot, ваш код отправляется на серверы Microsoft/OpenAI для генерации подсказок. По умолчанию, в бесплатных и индивидуальных платных подписках, этот код может использоваться для тренировки следующих версий моделей. В корпоративных подписках (Copilot Business, Copilot Enterprise) Microsoft обещает не использовать данные клиентов для тренировки. Но факт того, что есть разница между тарифами, показывает: для дешёвых тарифов ваш код — это тренировочные данные.

ChatGPT, Claude, Gemini. Аналогично: в индивидуальных подписках данные могут использоваться для тренировки, в корпоративных — обычно нет. Это разница не в качестве сервиса, а в юридических ограничениях использования данных.

Adobe Creative Cloud. История с условиями использования 2024-го года показала, что разработчики коммерческого ПО рассматривают пользовательский контент как потенциальный тренировочный материал. Adobe потом извинился и переписал условия, но осадок остался.

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

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

Это особенно болезненно для творческих профессий. Художники, которые годами загружали свои работы в Behance, ArtStation, в облачные сервисы, обнаружили, что их работы стали тренировочным материалом для моделей, которые теперь генерируют похожие изображения за минуты. Программисты обнаружили, что их open-source код использовался для обучения Copilot. Это не воровство в юридическом смысле (часто это разрешено условиями использования, на которые вы согласились). Но это качественно новое отношение между сервисом и пользователем.

11. Импульс «переписать всё под себя»

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

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

В каждом отдельном случае я могу пожать плечами. В сумме — нет.

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

Self-hosting — самостоятельная установка серверных сервисов у себя дома или на VPS — стал отдельной субкультурой. Из значимых проектов:

Nextcloud — open-source замена Google Drive, Office 365, Calendar, Contacts. Ставится на свой сервер, синхронизирует файлы между устройствами, имеет приложения для всех платформ. На 2026 год — это, наверное, главный self-hosted проект Европы.

Synapse / Matrix — open-source мессенджер на базе протокола Matrix. Можно поставить свой сервер, переписываться с другими серверами по федеративному протоколу. Используется правительством Германии (для внутренних коммуникаций), французской армией и многими другими организациями, которым важна суверенность.

Vaultwarden — self-hosted менеджер паролей, совместимый с клиентами Bitwarden. Полностью под вашим контролем.

Plausible / Umami — простая веб-аналитика без cookies и без отправки данных третьим сторонам, ставится на свой сервер.

Tailscale или его open-source аналог Headscale — VPN-mesh для связи ваших устройств без обращения к чужим серверам.

Mailcow / Mail-in-a-Box — готовые сборки почтового сервера для self-hosting. Технически работают, но требуют постоянного внимания (DNS, репутация IP, спам-фильтры).

Jellyfin — open-source замена Plex/Netflix для собственного медиа-сервера.

Forgejo / Gitea — self-hosted альтернативы GitHub для хранения собственного кода.

Это работающие проекты. Их ставят и пользуются. Не миллионы людей, но десятки тысяч точно. И каждый человек, который ставит себе Nextcloud, проводит маленький эксперимент: возможно ли в 2026 году жить с собственной инфраструктурой?

12. Где self-hosting утопия

Честно скажу: полный отказ от чужих сервисов невозможен. Есть категории, в которых self-hosting не работает.

Поиск в интернете. Поднять у себя дома индекс всего интернета вы не можете. Возможны компромиссы — мета-поисковики вроде SearXNG, которые проксируют ваши запросы в Google/Bing/DuckDuckGo, не позволяя последним связать запросы с вами. Это работает, но это не полная независимость.

Карты. Open Street Map — отличный проект, но без коммерческих сервисов вы не получите актуальные данные о пробках, время в пути с учётом транспорта, корректные данные о бизнесах. Можно сделать многое. Идеала не будет.

Большие модели ИИ. Локально можно запустить модели до примерно 70 миллиардов параметров (на мощном железе). Это полезно, и многие модели open source — Llama, Mistral, DeepSeek, Qwen — отличного качества. Но самые мощные на сегодня модели (Claude Opus, GPT-5, Gemini Ultra) у вас дома не работают: они слишком большие, чтобы поместиться в память даже самой дорогой потребительской видеокарты. Если вам нужен лучший доступный ИИ, придётся использовать чужие серверы.

Коммуникации с миром, который не self-host. Ваши друзья и знакомые не поставят себе Matrix-сервер. Коллеги работают в чужих сервисах: в моём случае это российские Контур.Толк (KTalk), Loop, Yonote, Яндекс Документы. Раньше я общался с большинством знакомых в Telegram, но после того как в РФ его сначала жёстко замедлили, а потом и заблокировали, многие переехали в государственный мессенджер MAX (его в августе 2025 года Госдума официально сделала «национальной коммуникационной платформой», а позже сделала обязательным к предустановке на новые смартфоны и планшеты). На моих устройствах MAX я ставить не собираюсь, но это означает, что часть привычного круга общения из моей картины мира фактически выпала.

Финансы, документы, государственные сервисы. Банковские приложения, госуслуги, налоговые сервисы — здесь self-hosting невозможен по определению. Это инфраструктура внешних организаций.

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

Категория «критически важное» — то, что должно быть под моим прямым контролем. Тексты, исходный код, личные документы, фотографии, переписка с близкими. Сюда self-hosting подходит идеально.

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

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

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

13. Почему OpenBSD: серьёзный разбор

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

OpenBSD — операционная система, появившаяся в октябре 1995 года как форк NetBSD. Её основатель и до сих пор основной идеолог — Тео де Раадт (Theo de Raadt), южноафрикано-канадский разработчик, известный исключительной строгостью технических стандартов и тем, что он никогда не поступается принципами ради чьего-то удобства.

Главное про OpenBSD: это первая в мире коммерческая операционная система, чьим главным архитектурным приоритетом является безопасность. Не функциональность. Не удобство. Не совместимость. Безопасность.

Известный неофициальный слоган проекта:

Only two remote holes in the default install, in a heck of a long time! («За много лет — всего две удалённые уязвимости в установке по умолчанию!»)

Это правда. Если посчитать критические удалённые уязвимости, которые позволяли скомпрометировать OpenBSD без действий пользователя, за тридцать лет их было всего две. Для сравнения, у Windows или Linux таких уязвимостей обнаруживают десятки в год.

Почему так? Несколько практик, которые OpenBSD культивирует более жёстко, чем другие системы.

Полный аудит кода. В первые годы проекта команда OpenBSD прошла построчным аудитом весь базовый дистрибутив. Не «нашли несколько багов и поправили», а систематический пересмотр каждой строки кода с точки зрения безопасности. Эта практика продолжается на новом коде.

Минимализм по умолчанию. В установке OpenBSD по умолчанию включены минимально необходимые службы. SSH-сервер работает, но больше почти ничего. Хотите веб-сервер — поставьте сами и сконфигурируйте. Это сильно отличается от Linux-дистрибутивов, где «всё включено», и от Windows, где значительная часть сервисов запущена «на всякий случай».

Безопасные значения по умолчанию. Если в системе есть выбор «удобнее vs безопаснее», OpenBSD почти всегда выбирает «безопаснее». Демоны запускаются от непривилегированных пользователей, в chroot. Конфигурации по умолчанию строгие.

Собственные технологии безопасности. Многие техники, которые потом перекочевали в Linux, Windows и macOS, появились в OpenBSD первыми:

W^X (write XOR execute) — память может быть либо записываемой, либо исполняемой, но не одновременно. Внедрено в 2003 году.
Address Space Layout Randomization (ASLR) — рандомизация адресов памяти, чтобы атакующий не мог надёжно эксплуатировать уязвимости. OpenBSD внедрил полноценный ASLR раньше других массовых систем.
pledge() (2015, OpenBSD 5.9) — системный вызов, через который программа сама себя ограничивает: «я обещаю системе, что буду использовать только эти возможности». Если программа потом попытается сделать что-то за пределами обещания, ядро её убьёт. Это драматически уменьшает поверхность атаки.
unveil() (2018, OpenBSD 6.4) — то же самое для файловой системы: «я обещаю, что буду читать только эти каталоги, писать только в эти». Любая попытка выйти за пределы — мгновенный SIGKILL.
LibreSSL — форк OpenSSL после катастрофической уязвимости Heartbleed в апреле 2014 года. Команда OpenBSD проанализировала OpenSSL и пришла в ужас от качества кода. За пару месяцев выкинули из него больше половины — мёртвый код, поддержку VMS и древних платформ, странные обходные пути, накопившиеся за десятилетия. То, что осталось, и есть LibreSSL — намного чище, безопаснее, аудируемее. По умолчанию используется в OpenBSD и нескольких Linux-дистрибутивах.
OpenSSH — да, тот самый, которым пользуется весь интернет, тоже родом из OpenBSD. Команда сделала из коммерческого SSH 1996 года полностью открытую реализацию, и за 25 лет OpenSSH стал стандартом удалённого доступа на всех Unix-подобных системах. Это, возможно, самый успешный экспортный продукт OpenBSD-проекта.
PF (Packet Filter) — один из лучших файрволов в мире, простой в конфигурации, отлично документированный.
doas — минималистичная замена sudo, написанная с нуля с акцентом на простоту и отсутствие сюрпризов.

Скромные системные требования. OpenBSD прекрасно работает на старом железе. Для текстовой работы и программирования хватает компьютера десятилетней давности. Я ставлю на SSD, у меня будет работать с запасом.

Графическое окружение. Из коробки OpenBSD предлагает Xfce — лёгкое и при этом функциональное окружение, которое отлично подходит для повседневной работы. Также есть варианты с i3 или dwm для тех, кто предпочитает тайлинговые менеджеры. Браузер (Firefox или Chromium), текстовый редактор (Neovim, Emacs), офисные пакеты (LibreOffice), редакторы изображений (GIMP, Krita) — всё работает.

Не идеально для всего. Честно: на OpenBSD нет некоторых коммерческих программ. Adobe Creative Cloud не работает. Игры в Steam — в основном нет, но мне и не надо, потому что я не играю. Корпоративные клиенты типа Microsoft Teams или Slack мне не нужны. Если ваша работа требует одной из этих вещей, OpenBSD как основная система не подойдёт.

Но для писателя, программиста, человека, работающего с текстом, кодом, лёгкой графикой OpenBSD сегодня идеальна. И это, наверное, главная причина, почему я серьёзно собираюсь его поставить. Не из идеологии. Из практичности.

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

14. Финал: новая дисциплина

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

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

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

Эти условия я бы сформулировал так: нулевое доверие как новая дисциплина. Не паранойя, не отказ, не изоляция. А постоянная привычка задавать себе вопросы:

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

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

И эта новая архитектура — не отказ от современного мира, а возвращение контроля. Я хочу быть хозяином своих инструментов, а не аккаунтом в чужой системе.

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

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

В следующих материалах я планирую вернуться к этой теме с практической стороны. Отдельный пост про OpenBSD как рабочее место. Возможно, отдельный материал про self-hosting с конкретными рекомендациями. И, обязательно, материал про цепочку поставок программного обеспечения — это огромная отдельная тема, которую xz-инцидент сделал критически важной.

Если этот пост заставил вас задуматься о собственных цифровых привычках — значит, время потрачено не зря. Возвращение контроля начинается с того, чтобы заметить, где вы его потеряли.

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

Конкретные случаи

ProtonMail и французская климатическая активистка (сентябрь 2021) — официальное заявление ProtonMail после скандала.
Andres Freund, оригинальный пост про xz backdoor (29 марта 2024) — открытие, изменившее представление о цепочке поставок.
Microsoft Recall security analysis (Kevin Beaumont, май 2024) — разбор первоначальной уязвимости.
Adobe Terms of Service controversy (июнь 2024) — официальное объяснение Adobe.
npm event-stream incident (2018) — Доминик Тарр объясняет, как он передал права.

Self-hosting

awesome-selfhosted — главный каталог open-source self-hostable приложений.
Nextcloud — облако.
Matrix.org — мессенджер.
Vaultwarden — пароли.
Tailscale / Headscale — VPN.

OpenBSD

OpenBSD.org — официальный сайт.
OpenBSD Innovations — список технологий безопасности, разработанных в проекте.
Theo de Raadt biography — основатель и идеолог.
«Absolute OpenBSD» (Michael W. Lucas) — главная книга для практической работы с OpenBSD.

Приватность и инфраструктура

Signal Foundation
Electronic Frontier Foundation — лучший правозащитный ресурс по цифровым правам.
Privacy Guides — практические рекомендации.
xkcd 2347 «Dependency» — то самое.

Tree-sitter: парсер на каждое нажатие клавиши

2026-06-01T19:35:18.974Z

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

Технология, которая это делает, называется Tree-sitter. Она умеет не разбирать файл заново при каждом изменении: получив редактирование, Tree-sitter понимает, какая именно часть синтаксического дерева затронута, и переразбирает только её. Всё, что не задето правкой, переиспользуется как есть.

Это давняя мечта инструментальной разработки. Десятилетиями редакторы решали задачу подсветки синтаксиса костылями: либо медленно перепарсивали файл целиком (страдает скорость), либо использовали поверхностные регулярки на каждую строку (страдает точность). Tree-sitter впервые дал способ иметь и точность настоящего парсера, и скорость, достаточную для интерактивной работы. Это изменило мир редакторов — и в 2026 году Tree-sitter стоит в Neovim, в Emacs 29, на GitHub.com, в новых редакторах Helix, Lapce, Zed, в форке Atom под именем Pulsar, в десятках инструментов разработки.

Этот пост — история Tree-sitter. Я расскажу, что было до него (TextMate-грамматики и их многолетние мучения), как Макс Брунсфельд в 2013 году начал писать Tree-sitter параллельно со своей основной работой, и как через пять лет проект стал стандартом редактора Atom. Объясню архитектуру (инкрементальный GLR-парсер с восстановлением ошибок) и почему это правильное архитектурное решение для задачи. Доберусь до Neovim 0.5, Emacs 29, GitHub code search Blackbird. И в финале вы узнаете что Tree-sitter делает, чего не делает, и где он точно не справится.

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

1. До Tree-sitter: эпоха TextMate-грамматик

С середины 2000-х и примерно до 2018 года стандартом подсветки синтаксиса в редакторах кода были TextMate-грамматики. Их формат возник в редакторе TextMate Аллана Одгаарда (Allan Odgaard, 2004 год, macOS). Сам TextMate был культовым редактором середины 2000-х, и его подход к подсветке оказался настолько практичным, что его скопировали Sublime Text, Visual Studio Code, GitHub Linguist (тот, что подсвечивает синтаксис файлов у вас в репозитории), и многие другие.

TextMate-грамматика — это plist или JSON-файл с регулярными выражениями. Грамматика задаёт паттерны вида:

{
  "name": "keyword.control.javascript",
  "match": "\\b(if|else|while|for|return)\\b"
}

Или более сложные, с парными begin/end:

{
  "name": "string.quoted.double.javascript",
  "begin": "\"",
  "end": "\"",
  "patterns": [{ "include": "#string-escape" }]
}

Редактор пробегает по тексту, применяет паттерны, расставляет «scope» (категории) на каждом символе. Категории вроде keyword.control.javascript, string.quoted.double.javascript, comment.line.double-slash потом отображаются разными цветами в зависимости от темы.

Это работало. Но у TextMate-грамматик было четыре больших проблемы.

Первая — точность. Регулярные выражения работают только в пределах одной строки. Если у вас многострочный комментарий или строка с переносами, грамматика начинает выкручиваться через begin/end с продолжением состояния. Это работает, но плохо: малейшая ошибка в исходнике, и подсветка «уезжает» до конца файла.

Вторая — невозможность сделать настоящую структуру. TextMate-грамматика подсвечивает токены, но не строит дерево. Она не знает, что function foo(a, b) { return a + b } — это объявление функции с двумя параметрами и телом. Она знает только: тут есть слово function, дальше идентификатор, потом скобки. Это значит, что любая фича, требующая понимания структуры — переход к определению, выделение функции целиком, рефакторинг — не получается из TextMate-грамматики.

Третья — сопровождаемость. Регулярки в TextMate-грамматиках сложных языков (TypeScript, C++, Rust) превращаются в монстров из сотен правил с десятками capture-групп и хитрых escape-последовательностей. Канонический пример — TypeScript TmLanguage, у которого в репозитории больше пятисот открытых issues с багами в подсветке синтаксиса. Поддерживать такую грамматику — отдельная инженерная боль.

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

К середине 2010-х индустрия понимала, что TextMate-подход — это тупик. Нужно что-то другое.

2. Макс Брунсфельд и старт проекта

В 2013 году в Pivotal Labs работал программист по имени Макс Брунсфельд. Pivotal — известная консалтинговая компания, специализирующаяся на agile-разработке и Ruby-проектах. Брунсфельд писал на Ruby, JavaScript, занимался разными клиентскими проектами. И в свободное от работы время он начал работу над Tree-sitter — библиотекой, которая должна была правильно решить проблему подсветки кода.

Первый коммит в репозиторий Tree-sitter датируется 6 ноября 2013 года. На тот момент это был сторонний проект — Брунсфельд писал его «по ночам и выходным». Он не был частью никакой большой компании, и не был обеспечен корпоративными ресурсами. Это была идея одного программиста, который заметил конкретную инженерную задачу и решил её решить.

Цель Брунсфельда была такая: построить настоящий парсер, который строит синтаксическое дерево, и при этом достаточно быстрый, чтобы работать в редакторе в реальном времени. Он понимал, что классические парсер-генераторы (Yacc, Bison, ANTLR) для этой задачи не подходят, потому что дают слишком медленные парсеры, они не умеют ни восстанавливаться после ошибок, ни инкрементально переразбирать изменившиеся куски.

К 2013 году Брунсфельд перешёл в команду Atom в GitHub. Atom — это новый редактор, который GitHub запускал как попытку конкурировать с Sublime Text и подготовиться к веб-эпохе разработки. Atom был построен на Electron (первая широкая известная реализация подхода «нативное приложение на веб-технологиях»), и его команда была заинтересована во всех способах сделать подсветку синтаксиса лучше. Идея Брунсфельда про Tree-sitter оказалась в нужном месте в нужный момент.

Следующие пять лет Брунсфельд работал в команде Atom и параллельно развивал Tree-sitter. Большая часть времени уходила на алгоритмическое исследование — какой именно тип парсера лучше подходит для инкрементальной задачи. Перебиралось несколько вариантов: PEG, LL(*), классический LR. В итоге Брунсфельд остановился на обобщённом LR (GLR), который был расширен инкрементальностью и восстановлением ошибок.

3. Atom 1.31 и Strange Loop 2018

Публичный анонс Tree-sitter состоялся 26 сентября 2018 года, когда вышел релиз Atom 1.31. В этой версии Tree-sitter был включён по умолчанию (на бета-канале) как новая система подсветки и индентации. Поддерживались одиннадцать языков: Bash, C, C++, ERB, EJS, Go, HTML, JavaScript, Python, Ruby, TypeScript. GitHub опубликовал в своём блоге пост «Atom understands your code better than ever before», в котором объяснил идею.

Через несколько дней Брунсфельд представил Tree-sitter на конференции Strange Loop 2018 в Сент-Луисе. Его доклад называется «Tree-sitter: a new parsing system for programming tools» и до сих пор остаётся самой цитируемой канонической презентацией Tree-sitter. Если вы хотите глубоко понять, как Tree-sitter устроен изнутри, этот доклад — лучшая точка входа.

Strange Loop — конференция, известная тем, что туда отбирают доклады про действительно интересные идеи, а не про практические инструменты. Tree-sitter выглядел в этом контексте отлично: это был не «новый редактор», а новая алгоритмическая идея, реализованная как библиотека.

Через пару лет, к 2020-му, экосистема вокруг Tree-sitter начала расти быстро. Появились грамматики для десятков языков, написанные сторонними разработчиками. Стали появляться плагины интеграции с другими редакторами. И вот тут начинается главное.

4. Архитектура: инкрементальный GLR

Прежде чем рассказать про распространение Tree-sitter в Neovim, Emacs и GitHub, разберёмся с тем, как он работает.

Tree-sitter — это инкрементальный GLR-парсер с восстановлением ошибок. Каждый из этих трёх кусков названия важен.

GLR (Generalized LR) — это обобщение классического LR-парсинга, придуманного Кнутом в 1965-м. Обычный LR парсит детерминированно: на каждом шаге у него один стек, и он либо сдвигает токен, либо сворачивает уже накопленную последовательность по правилу. Если возникает конфликт (можно сделать и то, и другое) — обычный LR умирает или требует переписать грамматику.

GLR в той же ситуации разветвляет стек и пробует обе возможности параллельно. Если одна из веток заходит в тупик, она отбрасывается. Если обе доходят до конца входа, грамматика неоднозначна, и парсер возвращает обе версии дерева. GLR придуман в 1980-х (Масару Томита, статья 1986 года), и до Tree-sitter его использовали в основном в академических компиляторах и для парсинга естественных языков.

Tree-sitter взял GLR, потому что он толерантен к неоднозначностям грамматики. Реальные языки программирования часто содержат локально-неоднозначные конструкции — например, a < b > (c) в C++ может быть и сравнением, и шаблонной инстанциацией, в зависимости от контекста. GLR может рассмотреть оба варианта и выбрать тот, который согласуется с дальнейшим текстом.

Инкрементальность — главная фишка Tree-sitter. Когда вы редактируете файл, парсер не разбирает его заново. Tree-sitter получает редактирование (edit) в виде «начиная с символа X, удалено N байт, вставлено M байт». На основе этого редактирования он понимает, какие узлы старого дерева точно не изменились, и переиспользует их как есть. Только узлы, которые попадают в затронутую область или могут быть затронуты через изменение контекста, разбираются заново.

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

Инкрементальность работает за счёт того, что синтаксические деревья в Tree-sitter иммутабельны и разделяемы. Когда вы редактируете файл, старое дерево не меняется. Создаётся новое дерево, которое указывает на узлы старого там, где они не изменились. Это та же идея, что и persistent data structures в Clojure (которые я уже упоминал в посте про Lisp) — экономия за счёт переиспользования общих частей.

5. Восстановление ошибок

Третий кусок — восстановление после ошибок. Это критично для редактора, потому что код в процессе ввода почти всегда синтаксически некорректен. Когда вы только напечатали function foo(a, b и ещё не закрыли скобку, классический парсер скажет «syntax error» и остановится. А редактору в этот момент уже надо подсвечивать слово function как ключевое, идентификатор foo как имя функции, и параметры a, b как параметры.

Tree-sitter решает это через тот же GLR-механизм. При невозможности продолжать парсинг он пробует разные стратегии восстановления: пропустить следующий токен и продолжить; вставить пропущенный токен и продолжить; откатиться назад и попробовать другую интерпретацию. Из этих стратегий выбирается та, которая через несколько токенов даёт «лучший» результат — то есть синтаксически валидное продолжение с минимальным количеством ошибок.

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

Любопытно, что в Tree-sitter нет формального академического описания алгоритма восстановления. Главным источником остаётся доклад Брунсфельда на Strange Loop и сам код. В тикетах проекта периодически возникают просьбы написать аккуратную статью или хотя бы развёрнутую документацию, но за восемь лет ни у кого до этого так и не дошли руки — алгоритм работает в продакшене у миллионов пользователей, так что приходится читать исходники.

6. Грамматики на JavaScript

Чтобы добавить поддержку нового языка, нужно написать грамматику для Tree-sitter. Это делается на специальном JavaScript-DSL, описанном в файле grammar.js.

Выглядит это так:

module.exports = grammar({
  name: 'mylang',

  rules: {
    source_file: $ => repeat($._definition),
    _definition: $ => choice(
      $.function_definition,
      $.variable_declaration
    ),
    function_definition: $ => seq(
      'function',
      field('name', $.identifier),
      field('parameters', $.parameter_list),
      field('body', $.block)
    ),
    parameter_list: $ => seq(
      '(',
      optional(commaSep1($.identifier)),
      ')'
    ),
    block: $ => seq('{', repeat($._statement), '}'),
    identifier: $ => /[a-zA-Z_][a-zA-Z0-9_]*/,
    // ...
  }
});

Это компактнее и приятнее, чем традиционные BNF в Yacc. Доступны функции seq (последовательность), choice (выбор), repeat (повторение), optional, prec (приоритет), token, field (именованные поля для узлов), и ещё несколько. Грамматика — это обычный JavaScript-код, и в ней можно использовать любые JS-функции для генерации правил (типа commaSep1 в примере выше — это утилита, которая разворачивается в seq($.elem, repeat(seq(',', $.elem)))).

Команда tree-sitter generate парсит grammar.js, прогоняет через Node, получает промежуточное JSON-представление, и компилирует это в C-код парсера. Сам C-код длинный (десятки тысяч строк для крупного языка) и нечитаемый, но это машинно-сгенерированный код — его никто не правит руками.

Большая часть синтаксиса языков описывается грамматикой целиком. Но есть конструкции, которые контекстно-зависимы — например, значимые отступы в Python, где открытие и закрытие блоков определяются изменением уровня отступа. Такие штуки описываются в Tree-sitter через external scanner — ручной C/C++-код, который подключается к парсеру и решает контекстно-зависимые задачи. Это компромисс, но он работает.

На сегодня (2026 год) на GitHub есть более 300 грамматик для разных языков. Большинство сделано сообществом, флагманские (C, Python, JavaScript, Rust, Go) — в основной организации tree-sitter на GitHub. Качество грамматик сильно разное: некоторые отлично сделаны и быстро работают, другие имеют проблемы с производительностью или с покрытием экзотических конструкций.

7. Neovim 0.5: революция в редакторе

2 июля 2021 года вышел релиз Neovim 0.5. Это был один из самых значимых релизов в истории редактора за последние десять лет. Главное нововведение — встроенная поддержка Tree-sitter через новый Lua-API.

Чтобы понять, почему это важно, надо вспомнить контекст. Neovim — современный форк классического Vim, который начался в 2014 году с целью переписать Vim под современную инфраструктуру (асинхронные API, нативная поддержка Lua, встроенный LSP-клиент, нативные плагины). К 2020 году Neovim уже был зрелым редактором, и его сообщество искало способы сделать подсветку и навигацию по коду лучше, чем в классическом Vim, который десятилетиями использовал regex-based подсветку (в Vim она называется «syntax highlighting» и состоит из тысяч строк регулярок в файлах *.vim).

Tree-sitter в Neovim 0.5 был экспериментальным, с регрессиями и багами. Но направление было задано, и сообщество подхватило. Появился плагин nvim-treesitter — обёртка, которая ставит грамматики, конфигурирует подсветку, добавляет навигацию по структуре кода. К 2022–2023 годам этот плагин стал стандартом — практически каждый серьёзный пользователь Neovim его устанавливает.

С появлением Tree-sitter в Neovim родилась целая волна Lua-плагинов, которые используют синтаксическое дерево для умных операций: nvim-treesitter-textobjects (выделение целых функций, классов, блоков), treesitter-context (показ контекста текущей функции в виде «прилипшего» к верху окна), nvim-treehopper (быстрая навигация по узлам дерева), и десятки других. Это новая инструментальная экосистема, которой в классическом Vim не было.

8. Emacs 29: встроенная поддержка

Emacs прошёл тот же путь чуть позже. В июле 2023 года вышел Emacs 29 — первый релиз, в котором Tree-sitter стал встроенной частью редактора.

Модуль называется treesit (написан на C, плюс Lisp-обвязка). Грамматики подключаются как динамические библиотеки через команду treesit-install-language-grammar. В Emacs 29 встроены *-ts-mode для шестнадцати языков: C, C++, C#, Java, Rust, Go, Python, JavaScript, TypeScript, JSON, YAML, TOML, CSS, Bash, Dockerfile, CMake.

До этого в Emacs существовал сторонний пакет emacs-tree-sitter от Туан-Ань Нгуена (Tuấn-Anh Nguyễn), который сделал колоссальную работу по добавлению Tree-sitter в Emacs ещё в 2019–2020 годах. С релизом Emacs 29 этот пакет теперь рекомендует пользователям перейти на встроенный treesit — но именно работа Нгуена показала, что Tree-sitter в Emacs возможен и желанен, и подготовила почву для официальной интеграции.

В посте про Emacs я уже упоминал, что Emacs 29 принёс два важных нововведения: нативную компиляцию Emacs Lisp и Tree-sitter. Эти изменения сильно подтянули современный Emacs к уровню современных редакторов вроде VSCode — там, где раньше Emacs выглядел архаично, теперь он стал конкурентоспособен.

9. GitHub.com: новый поиск кода

Параллельно с интеграцией в редакторы Tree-sitter попал в сам GitHub.com. В 2022 году в публичную бету вышел новый поиск кода — внутренний кодовый проект под кодовым именем Blackbird. В 2023-м (полный анонс — пост «The technology behind GitHub’s new code search» от 6 февраля 2023) он стал общедоступным.

Blackbird — это система поиска по коду, которая работает на всех публичных репозиториях GitHub (это десятки терабайт исходников на сотнях языков). И для того, чтобы поиск был семантическим, то есть искал не просто текст, а функции, классы, переменные с пониманием их роли, нужен парсер на каждый язык.

GitHub выбрал Tree-sitter. В посте про архитектуру это написано прямо: «Enry и Tree-sitter питают language detection и symbol extraction Blackbird». То есть когда вы ищете на GitHub function MyFunc, поиск точно знает, что MyFunc — это имя функции, а не комментарий или строковый литерал. Это знание берётся из синтаксического дерева, построенного Tree-sitter.

Параллельно с Blackbird GitHub разработал Stack Graphs — фреймворк для точной навигации по коду (precise code navigation), который надстраивается над Tree-sitter. Stack Graphs решает задачу разрешения имён: когда вы кликаете на использование переменной, перейти к её определению, даже через несколько уровней импортов, наследований, скоупов. Это серьёзная задача, и Stack Graphs её решает поверх синтаксических деревьев Tree-sitter.

Параллельно GitHub в 2025 году архивировал свой старый проект Semantic — Haskell-библиотеку для семантического анализа кода, которая до Tree-sitter была основой code navigation на GitHub. То есть Tree-sitter не просто добавлен — он заменил предыдущее поколение инструментов в инфраструктуре одного из крупнейших сайтов разработки.

10. Новые редакторы: Helix, Lapce, Zed

К началу 2020-х Tree-sitter стал настолько хорошим решением, что новые редакторы, появившиеся в эти годы, строились с Tree-sitter в качестве центрального компонента подсветки и навигации.

Helix — модальный редактор на Rust, появившийся в 2020-м, вдохновлённый Vim и Kakoune. Tree-sitter в Helix — центральный движок подсветки, отступов и структурного редактирования. Helix не поддерживает Vim-плагины — у него своя архитектура, и Tree-sitter в неё встроен глубоко, не как опция, а как фундамент.

Lapce — графический редактор на Rust, использующий ту же Tree-sitter-реализацию, что и Helix (через MPL-лицензию). Lapce — попытка сделать «VSCode на Rust», и Tree-sitter там для подсветки и навигации.

Zed — отдельная история. Zed основали в 2021 году трое программистов из бывшей команды Atom: Макс Брунсфельд (тот самый создатель Tree-sitter), Натан Собо и Антонио Скандурра. Zed — это попытка с нуля сделать редактор, оптимизированный под производительность: написан на Rust, использует GPU для рендеринга, ориентирован на совместное редактирование. Tree-sitter в Zed — естественная часть архитектуры, и Брунсфельд продолжает его развивать прямо из своей роли соучредителя.

Zed был запущен публично в 2023-м, и за два года команда успела собрать в общей сложности около $42 млн венчурных инвестиций (в том числе крупный раунд от Sequoia в ноябре 2024-го). Это уже серьёзная редакторская компания, и она строится вокруг Tree-sitter как одной из своих ключевых технологий.

И тут возникает интересная картинка. Tree-sitter, начавшийся как сторонний проект одного программиста в Pivotal Labs в 2013 году, через десять лет стал технической основой нескольких новых редакторов, инфраструктуры GitHub и встроенной частью Emacs и Neovim. Это редкая история про то, как алгоритмическая идея превращается в стандарт индустрии.

Любопытно, что VSCode — самый популярный редактор мира — на Tree-sitter в основной подсветке до сих пор не перешёл. VSCode продолжает использовать TextMate-грамматики (со всеми их проблемами) для большинства языков. Tree-sitter применяется в нём только в отдельных расширениях. Это и есть лучшее напоминание о том, что универсального стандарта парсинга в индустрии всё ещё нет: даже самый массовый редактор не унифицировал свой стек на Tree-sitter — слишком много накопившегося легаси-кода и расширений, которые пришлось бы переписывать.

11. Что Tree-sitter не делает

Tree-sitter — отличный инструмент, но у него есть принципиальные ограничения, которые важно понимать.

Tree-sitter строит конкретное синтаксическое дерево (CST), а не абстрактное (AST). Разница такая: CST содержит все токены исходного кода, включая скобки, точки с запятой, ключевые слова, комментарии. AST — упрощённое дерево, в котором скобки и точки с запятой выкинуты, оставлена только семантическая структура. Для редакторов CST идеально: вы можете точно восстановить позицию каждого узла в исходнике, подсветить его, дать пользователю выделить целую функцию вместе со скобками. Но для компилятора CST избыточен — компилятор обычно хочет AST, и Tree-sitter не даёт его напрямую.

Tree-sitter не делает семантический анализ. Он не знает, что переменная x объявлена выше и сейчас используется. Он не знает типов. Он не знает, к какому классу относится метод. Всё это — задача надстроек (как Stack Graphs у GitHub, как LSP-сервер для каждого языка). Tree-sitter — это только синтаксис.

Tree-sitter не подходит для компилятора. Главная причина — он может «проглатывать» невалидный синтаксис и не помечать его как ошибку, чтобы продолжать парсинг. Для компилятора это катастрофично: он не должен принимать неверный код как валидный. Поэтому реальные компиляторы (Rust, Go, TypeScript) всё равно используют свои собственные парсеры — обычно рукописный рекурсивный спуск.

Грамматики сложно писать. JavaScript-DSL в целом понятный, но контекстно-зависимые конструкции требуют ручного внешнего сканера на C. Кроме самой грамматики, под каждый язык пишутся запросы подсветки — отдельные файлы, в которых конкретные узлы дерева помечаются именами вроде @function.call, @variable.builtin, @string и так далее. По этим именам редактор уже решает, каким цветом красить кусок текста. Беда в том, что единого словаря этих имён нет: Zed, Neovim и Helix используют немного разные наборы — и грамматики приходится править под каждый редактор отдельно.

Инкрементальность не всегда работает идеально. На очень больших файлах с плохо написанной грамматикой переразбор может занимать секунды. Известны кейсы: 1.6 МБ JSON-файл — полный парсинг 1.2 секунды, переразбор 0.7 секунды; 10 МБ C-файл — переразбор около тридцати секунд. Качество грамматики решает: переписывание tree-sitter-haskell с C++ на C дало 52-кратное ускорение. То есть «миллисекундный переразбор» — это честная цифра для нормальных файлов и нормальных грамматик, но бывают и патологические случаи.

12. Что и когда использовать в 2026 году

Если вы в 2026 году хотите использовать Tree-sitter в своём проекте, у вас есть несколько вариантов в зависимости от цели.

Подсветка синтаксиса и структурная навигация в собственном редакторе или IDE. Берите Tree-sitter — это сегодня стандарт. Есть готовые runtime-библиотеки на C, Rust, JavaScript, Python, Go, Java, Haskell. Грамматики для популярных языков уже написаны и поддерживаются сообществом.

Анализ кода в небольшом инструменте (линтер, форматтер, метрики). Tree-sitter — отличный вариант. Вам не нужно писать собственный парсер для каждого языка. Вы берёте существующую грамматику, и через несколько часов работы у вас есть синтаксическое дерево, по которому можно строить любые анализы. Лучше всего на Python (через py-tree-sitter) или Rust.

Подсветка в маленьком GUI или TUI приложении. Tree-sitter работает, но это может быть избыточно. Если вам нужно подсветить только два-три простых языка, TextMate-грамматики через vscode-textmate или просто свои regex-правила могут оказаться проще.

Парсер для собственного компилятора. Tree-sitter — не лучший выбор. Делайте рукописный рекурсивный спуск: именно так устроены парсеры всех современных серьёзных компиляторов (Rust, Go, TypeScript, Swift). Tree-sitter удобен для редакторов, потому что прощает ошибки; компилятор не должен прощать ошибки.

Семантический анализ (резолв имён, типы, кросс-файловая навигация). Tree-sitter сам этого не делает, но даёт фундамент. Сверху вам нужны Stack Graphs (от GitHub), LSP-сервер целевого языка, или своя реализация.

Интеграция Tree-sitter в существующий редактор. Если вы пишете плагин для Neovim, Emacs или VSCode и хотите использовать дерево синтаксиса — у Tree-sitter есть API во всех этих экосистемах. Это самый быстрый способ начать.

13. Финал: парсер, ставший инфраструктурой

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

В 2013-м Макс Брунсфельд начал писать инкрементальный парсер по вечерам, в свободное от Pivotal Labs время. В 2018-м Tree-sitter появился по умолчанию в Atom. В 2021-м — стал частью Neovim. В 2023-м — встроен в Emacs и в инфраструктуру поиска кода GitHub. В 2024-м — основа нового редактора Zed, на который Брунсфельд получил $32 миллиона венчурного капитала.

И при всём этом сам Tree-sitter остаётся открытой библиотекой на C с MIT-лицензией, в которую любой желающий может прислать pull request. Это та же модель, что и у Linux, Git, Python — инфраструктура, которой пользуются все, развивается сообществом без жёсткого корпоративного контроля.

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

Рядом стоит ещё одна большая инфраструктурная штука современной разработки — LSP (Language Server Protocol), который занимается уровнем выше Tree-sitter: семантикой языков, навигацией по символам, диагностикой. Tree-sitter и LSP отлично дополняют друг друга, и сегодня в любом современном редакторе они работают в связке. А что происходит после парсера — как из дерева получается машинный код, — это уже тема для отдельного большого поста про компиляторы целиком.

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

Главные источники

Видео

📺 Max Brunsfeld, «Tree-sitter — a new parsing system for programming tools» (Strange Loop 2018) — каноническая презентация автора. Лучшая точка входа в идеи Tree-sitter.

📺 Tree-sitter в Neovim — обзор и настройка

Грамматики и инструменты

Список флагманских грамматик — основная организация на GitHub.
tree-sitter-language-pack — пак с 300+ грамматиками для разных языков.
nvim-treesitter — основной плагин для Neovim.
emacs-tree-sitter — исторический пакет для Emacs до версии 29.

Применение

Neovim 0.5 release notes (июль 2021)
Tree-sitter in Emacs 29 and Beyond — Yuan Fu — подробный пост про интеграцию в Emacs 29.
Helix Tree-sitter integration — гайд по добавлению языков в Helix.
Zed Team — команда Zed, включая Брунсфельда.

Критика и ограничения

Issue #224: Document the error-recovery algorithm — обсуждение восстановления ошибок.
Speeding up tree-sitter-haskell 50x — кейс про оптимизацию плохо написанной грамматики.
Modern Tree-sitter, part 7 — Pulsar blog — серия постов от форка Atom о современных нюансах работы с Tree-sitter.

Эрик Реймонд: антипод Столлмана и крёстный отец open source

2026-05-31T19:49:48.527Z

27 мая 1997 года, Вюрцбург, Германия. Идёт первая международная конференция Linux Kongress. На сцену поднимается худой бородатый мужчина сорока лет с лёгкой неровностью в походке. У него за плечами — без малого тридцать лет жизни в хакерских сообществах, недописанный диплом математика и философа Пенсильванского университета, плотная переписка с половиной интернета и репутация человека, способного провести в споре на Usenet двенадцать часов подряд, не сходя со стула.

Он начинает доклад с тезиса, который через год перевернёт индустрию: что Linux разрабатывается принципиально иначе, чем любое серьёзное программное обеспечение до него, и что эта непохожесть — не случайность, а ключ к тому, почему за шесть лет с момента первого письма Линуса Торвальдса в юзенет-группе comp.os.minix свободное ядро операционной системы успело уделать половину коммерческих UNIX-вариантов.

Метафора, которую он использовал, простая до неловкости. Большое программное обеспечение, утверждает он, обычно строится как собор: иерархия архитекторов, тщательное планирование, длинные циклы разработки, всё проектируется заранее. А Linux собирается как базар: десятки людей одновременно тащат туда патчи, исправления, идеи, всё это шумно, хаотично, кажется, что развалится через неделю, но почему-то работает лучше любого собора. Доклад назывался «The Cathedral and the Bazaar» («Собор и базар»).

Через восемь месяцев, в январе 1998-го, корпорация Netscape публично объявит о решении открыть исходный код браузера и прямо сошлётся на этот доклад как на одну из причин. Ещё через две недели в офисе Foresight Institute в Лос-Альтосе соберётся небольшая группа людей, которые придумают термин «open source». И в течение следующих десяти лет этот термин полностью перепишет, что значит свободное программное обеспечение, как оно делается и кто на нём зарабатывает.

Человека на сцене зовут Эрик Стивен Реймонд. Его сокращённое имя — ESR — для следующих двадцати лет станет одним из самых узнаваемых трёхбуквенных тегов в мире хакеров: рядом с RMS (Ричард Мэттью Столлман) и LBT (Линус Бенедикт Торвальдс). Он будет идеологом, евангелистом, библиотекарем хакерской культуры — и одновременно одним из самых спорных её представителей. Его дружба будет заканчиваться скандалами. Его доклады будут менять индустрию. Его блог станет местом, где либертарианские взгляды на оружие, свободу и государство будут смешиваться с разбором архитектурных проблем NTP-демона.

Этот пост — о Реймонде. Я расскажу о его детстве в Венесуэле и о том, как лёгкий церебральный паралич привёл его к компьютерам, как он взял заброшенный словарь хакерского жаргона из лабораторий MIT и Stanford и собрал из него книгу. Доберусь до главного — до «Собора и базара» и до того, как из доклада в Германии вырос Open Source Initiative и сам термин «open source». Объясню, в чём именно расходятся он и Столлман — это не личная склока, это два разных взгляда на то, что вообще такое свобода в программном обеспечении. И, конечно, напишу о связанных с ним скандалах, его политических взглядах и о том, как в 2020-м его собственное движение отказалось его терпеть.

Если вы читали мои предыдущие посты про Столлмана, Emacs и Lisp, то стоит отметить, что Реймонд — четвёртая фигура в той же истории. Без него рассказ о хакерской культуре конца XX века был бы неполным.

1. Бостон, Венесуэла, ДЦП и первые компьютеры

Эрик Стивен Реймонд родился 4 декабря 1957 года в Бостоне. Семья переезжала вслед за работой отца: в раннем детстве Эрик жил в Венесуэле, и испанский был одним из его первых языков. В 1971 году, когда ему было четырнадцать, семья окончательно осела в Пенсильвании.

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

В подростковом возрасте Реймонд оказался у компьютеров случайно — в школе появился доступ к терминалу с подключением к удалённой машине, и Эрик быстро понял, что эта штука гораздо интереснее всего, что предлагала школьная программа. Он научился программировать раньше, чем закончил школу, и к моменту поступления в Пенсильванский университет (UPenn) уже мог писать серьёзный код.

Любопытно, что в университете Реймонд изучал не информатику. Его официальные специальности — математика и философия. Тогда информатики как отдельной дисциплины в UPenn практически не было. Те, кто хотели программировать, шли через математику или электротехнику. Реймонд диплом так и не получил — ушёл из университета, не закончив обучение. Программированию он научился сам: книги, документация, доступ к BBS и ARPANET, переписка со старшими хакерами.

Это, кстати, одна из его отличительных черт. Реймонд — самоучка без академического признания, и он этим гордится. Всю свою карьеру он будет утверждать, что хакерство — это не дипломы, а способность довести задачу до работающего кода. Эта позиция потом ляжет в фундамент его эссе «How to Become a Hacker» и определит его отношение к индустрии.

2. Хакерская культура и Jargon File

В 1980-е Реймонд активно участвует в Usenet — глобальной сети новостных групп, которая в те годы выполняла роль одновременно Reddit, Stack Overflow, Twitter и личных блогов. В группах вроде comp.lang.lisp, comp.os.unix.minix, alt.folklore.computers он становится одним из заметных авторов — пишет длинно, технически грамотно, не боится полемики.

Именно в этой среде он сталкивается с тем, что станет его первым крупным проектом — The Jargon File.

The Jargon File — это словарь хакерского жаргона, который начиная с 1975 года вели в Stanford AI Lab (изначально Рафаэль Финкель, потом Дон Вудс). Через несколько лет файл начал параллельно поддерживаться в MIT AI Lab. Это был не словарь в академическом смысле, а культурный документ — попытка зафиксировать сленг, идиомы, шутки, легенды того поколения программистов, которые сами называли себя хакерами в исходном, доинтернетовском смысле слова: «люди, которые пишут красивый код и получают от этого удовольствие».

К 1983 году файл лёг в основу первого книжного издания — The Hacker’s Dictionary под редакцией Гая Стила-младшего (Harper & Row, 1983). И после этого работа над файлом фактически прекратилась. Лаборатория искусственного интеллекта начала распадаться (отчасти из-за истории с Symbolics, которая описана в посте про Столлмана), и поддерживать словарь стало некому.

В 1990 году Эрик Реймонд взял Jargon File на себя. Возрождённая версия 2.1.1 вышла 12 июня 1990 года. Все изменения Реймонд согласовывал с Гаем Стилом, чтобы сохранить дух оригинала. Через год, в 1991-м, новая версия легла в основу книги «The New Hacker’s Dictionary» (MIT Press, ISBN 0-262-68069-6). Второе издание вышло в 1993-м, третье — в 1996-м.

The New Hacker’s Dictionary — это, наверное, лучший культурный артефакт о хакерах конца XX века. Там есть всё: история термина «foo», объяснение, почему программисты говорят «yak shaving», легенда про PDP-1 и игру Spacewar!, шутки про язык программирования INTERCAL, разбор разницы между «hacker» в исходном смысле и «cracker» (которым стали называть взломщиков). Если вы хотите понять, откуда выросла культура, в которой потом появятся Emacs, Linux, Python, Stack Overflow и Hacker News, — этот словарь лучшая точка входа.

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

3. «How to Become a Hacker» (1996)

В конце 1996 года Реймонд публикует на своём сайте эссе под названием «How to Become a Hacker» — «Как стать хакером».

Эссе короткое, личное и абсолютно непохожее на тогдашние учебники. Реймонд не объясняет, как писать код, и не учит конкретным языкам. Вместо этого он отвечает на вопрос, который ему уже несколько лет задают молодые программисты в Usenet: «как мне стать настоящим хакером?». И отвечает он этически, а не технически.

Хакер, говорит Реймонд, — это не человек, который ломает чужие системы (это крэкер, и хакеры презирают крэкеров). Хакер — это человек, который строит вещи, который относится к программированию как к искусству, который верит в обмен знаниями и в открытое сотрудничество. Хакерство — это позиция в мире, способ думать. Технические навыки приложатся.

В эссе есть длинный список рекомендаций: учи Python (он легче, чем C, и при этом мощный), учи C (потому что без него ты не поймёшь UNIX), учи Perl (потому что половина системного администрирования написана на нём), учи Lisp — даже если ты никогда на нём не напишешь ни строчки серьёзного кода. Именно про Lisp в этом эссе появляется одна из самых цитируемых фраз во всей истории нашей профессии:

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

Я уже цитировал эту фразу в посте про Lisp — она там стала кульминацией всей истории. Источник её — именно «How to Become a Hacker». Это, в сущности, одно предложение, в котором Реймонд формулирует то, что считает главным в хакерской культуре: ты учишься не ради сертификата и не ради зарплаты, ты учишься ради того, чтобы лучше думать.

Эссе с тех пор обновляется примерно раз в год. Его переводы на десятки языков. Его читают молодые программисты в 2026-м точно так же, как читали в 1997-м. Это, наверное, самый известный текст Реймонда после «Собора и базара».

4. fetchmail и эксперимент с открытой разработкой

Параллельно с эссеистикой Реймонд писал код. В июне 1996 года он взял на сопровождение небольшую программу под названием popclient — клиент для получения почты через протокол POP3, изначально написанный программистом Карлом Харрисом. Через несколько месяцев Реймонд переименовал её в fetchmail, добавил поддержку IMAP, форвардинг через SMTP, расширенную конфигурацию.

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

Именно опыт fetchmail лёг в основу эссе «The Cathedral and the Bazaar», которое он представит через несколько месяцев. В этом эссе fetchmail будет главным примером — конкретный кейс, на котором Реймонд иллюстрирует, как именно работает «базарная» модель.

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

5. «The Cathedral and the Bazaar» (1997)

27 мая 1997 года Реймонд представил на конференции Linux Kongress в Вюрцбурге доклад «The Cathedral and the Bazaar». Через несколько месяцев он расширил текст и опубликовал его в виде эссе. В 1999 году вышла книга в издательстве O’Reilly (ISBN 1-56592-724-9), куда вошли это эссе и ещё несколько связанных текстов: «Homesteading the Noosphere», «The Magic Cauldron» и другие.

Главный тезис эссе формулируется просто. Существуют две модели разработки сложного программного обеспечения:

Модель «собора». Архитекторы заранее проектируют всё устройство системы. Разработка идёт за закрытыми дверями. Релизы редкие, тщательно подготовленные. Качество достигается долгим планированием и контролем со стороны узкой группы людей. По этой модели делается коммерческий софт, и так же изначально делался GNU.

Модель «базара». Никакого единого плана нет. Десятки или сотни людей одновременно тащат в проект патчи, исправления, фичи. Релизы выходят часто и небольшие. Качество достигается тем, что «при достаточном количестве глаз все ошибки лежат на поверхности» — знаменитый закон Линуса, сформулированный в этом же эссе:

Given enough eyeballs, all bugs are shallow.

Реймонд утверждает: Linux был построен по модели базара, и поэтому к 1997 году обогнал коммерческие UNIX-варианты. Не потому, что Торвальдс гений (хотя он гений), а потому, что архитектура разработки оказалась принципиально более эффективной для большого ПО.

Эссе попало в самую точку времени. Linux к 1997-му уже был серьёзной системой, но индустрия всё ещё относилась к нему как к курьёзу. «Собор и базар» дал индустрии язык, на котором можно было обсуждать феномен Linux всерьёз. Корпоративные технические директора, которые до этого мялись с ответом на вопрос «почему мы не используем Linux вместо Solaris», теперь могли сослаться на конкретную статью.

Чудо состоит в том, что Реймонд не написал учебник по программированию. Он написал манифест культуры, и манифест оказался достаточно убедительным, чтобы изменить корпоративные решения. До 1997-го открытое программное обеспечение в глазах CIO крупных компаний было любительщиной. После — стало стратегически значимой технологией.

6. Netscape, январь 1998

Через семь месяцев после доклада в Вюрцбурге, 22 января 1998 года, корпорация Netscape объявила о решении открыть исходный код своего браузера. Это была сенсация: Netscape была крупной коммерческой компанией с миллиардной капитализацией, а её браузер — основным конкурентом Internet Explorer. Открытие исходников означало, что Netscape будет конкурировать с Microsoft не как компания против компании, а как открытое сообщество против корпоративной монополии.

В корпоративном меморандуме, подготовившем это решение, — документе под названием «Netscape Source Code as Netscape Product», написанном Фрэнком Хекером осенью 1997 года, — «The Cathedral and the Bazaar» цитируется как одно из ключевых внешних подтверждений идеи. Сам Реймонд был приглашён в штаб-квартиру Netscape 4 февраля 1998-го на стратегическую сессию по плану релиза. CEO Netscape Джим Барксдейл публично называл эссе «одним из главных влияний» на это решение.

С этого момента Реймонд стал известным человеком за пределами хакерского сообщества. О нём писали в Wired, Forbes, Fortune. Его звали выступать на корпоративных конференциях. Его эссе стали обязательным чтением для технологических предпринимателей.

И именно в этот момент возникла идея, что для разговора с индустрией нужен другой язык. Не «free software», как у Столлмана, — слово «free» по-английски слишком неоднозначно (free as in freedom vs free as in beer), а корпоративный мир инстинктивно настораживается, когда видит слово «free». Нужен новый бренд.

7. Лос-Альтос, 3 февраля 1998: рождение термина «open source»

Через двенадцать дней после анонса Netscape, 3 февраля 1998 года, в офисе Foresight Institute в Лос-Альтосе (Калифорния, не путать с Пало-Альто — это разные города в нескольких километрах друг от друга) собралась небольшая группа людей. Присутствовали:

Кристин Петерсон — соучредитель Foresight Institute, известная футурологом и популяризатор нанотехнологий;
Эрик Реймонд;
Брайан Белендорф — один из основателей Apache;
Майкл Тиман — основатель Cygnus Solutions, первой коммерческой компании, зарабатывавшей на свободном ПО;
Тодд Андерсон;
Марк С. Миллер — программист и философ;
Ка-Пинг Йи — программист и активист.

Целью встречи было обсудить, как индустрия должна реагировать на анонс Netscape. И в ходе разговора Кристин Петерсон предложила термин «open source» — буквально «открытый исходный код». Идея понравилась. Реймонд её активно поддержал. Через два дня, 5 февраля 1998-го, во второй встрече в офисе VA Research участвовали уже Ларри Аугустин, Сэм Окман, по телефону подключался Джон «maddog» Холл — там окончательно решили, что термин принимается как новый бренд для движения свободного программного обеспечения, ориентированный на бизнес.

9 февраля 1998 года была опубликована Open Source Definition (OSD) — формальное определение того, что считается open source. Через несколько недель Реймонд и Брюс Перенс (автор Debian Free Software Guidelines, на основе которых писался OSD) учредили Open Source Initiative (OSI) — некоммерческую организацию для продвижения и защиты термина. Реймонд стал её первым президентом, Перенс — вице-президентом.

Ребрендинг сработал ошеломляюще. В течение следующих двух-трёх лет почти вся индустрия начала говорить «open source» вместо «free software» или «freeware». IBM, Sun, Oracle, Hewlett-Packard — все крупные технологические компании конца 1990-х приняли термин и начали публично поддерживать соответствующие проекты. Linux перестал быть «программой для бородатых анархистов» и превратился в респектабельную инфраструктуру.

И это, конечно, было катастрофой с точки зрения Ричарда Столлмана.

8. Раскол со Столлманом

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

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

Для Реймонда свободное программное обеспечение — это прагматическая стратегия. Открытость кода позволяет разрабатывать ПО эффективнее, потому что задействует распределённое сообщество. Это аргумент для инженеров и менеджеров, а не для философов. Если можно убедить корпорации использовать и поддерживать открытое ПО, потому что это экономически выгодно, — это победа. Этика, по мнению Реймонда, отпугивает индустрию и тормозит распространение. «Open source» — это переименование, специально предназначенное для того, чтобы в разговоре с бизнесом не упоминать никакой философии.

Столлман принципиально отказался признавать новый термин. В своих текстах он систематически писал «free software, sometimes called open source» и многократно объяснял, почему это не одно и то же. Самая известная его формулировка: «Open source — это не движение, потому что у него нет цели, кроме как сделать работающий код. У free software цель — этическая. Это разные вещи».

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

Этот раскол продолжается до сих пор. В 2026 году в сети по-прежнему живут оба лагеря: Free Software Foundation (FSF), которую возглавляет Столлман, со строгой этической позицией, и Open Source Initiative (OSI), которая после ухода Столлмана из её ближайшего окружения постепенно эволюционировала в более либеральном корпоративно-дружественном направлении.

Любопытно, что технически разница между «free software» и «open source» практически нулевая. Open Source Definition (OSD) перекрывает примерно тот же набор лицензий, что и Free Software Definition. Если программа свободная по Столлману, она же — open source по Реймонду. Различие — исключительно в риторике и аудитории.

Но в риторике, как показала вся история программирования последних тридцати лет, дьявол как раз и сидит.

Брюс Перенс, кстати, ушёл из OSI уже в феврале 1999 года, через год после её основания, написав, что Реймонд «теряет фокус на свободном программном обеспечении». Это была первая трещина в коалиции; за ней последуют другие.

9. «The Art of Unix Programming» (2003)

После пика open-source-революции 1998–2000 годов Реймонд занялся книгой, которая должна была кодифицировать всё, что он знал о философии UNIX как технологической культуры.

«The Art of Unix Programming» вышла 23 сентября 2003 года в издательстве Addison-Wesley (ISBN 0-13-142901-9, около 560 страниц). Это толстая книга, в которой Реймонд формулирует 17 правил философии UNIX: правило модульности, правило ясности, правило композиции, правило разделения, правило простоты, правило экономии, правило прозрачности, правило надёжности, правило репрезентации, правило наименьшего удивления, правило тишины, правило восстановления, правило экономии (разработчиков), правило генерации, правило оптимизации, правило разнообразия, правило расширяемости.

Это не учебник. Это манифест культуры. Реймонд утверждает, что UNIX — не просто операционная система, а особый способ думать о программном обеспечении: маленькие хорошо сделанные инструменты, текстовые потоки как универсальный интерфейс, удобство комбинирования, человекочитаемые конфигурационные файлы. И этот способ думать был сформирован в Bell Labs в 1970-е (Кен Томпсон, Деннис Ритчи, Дуглас Макилрой, Брайан Керниган) — и до сих пор сохраняется в современных дистрибутивах Linux, в BSD, в macOS под капотом.

«The Art of Unix Programming» сильно повлияла на отношение к разработке системного ПО. Не все её правила прижились (некоторые сильно устарели, как правила про текстовые потоки — современные данные часто структурированные, JSON или Protobuf, а не plaintext), но как культурный документ книга остаётся обязательной к прочтению. Она доступна онлайн под Creative Commons.

10. Программистский вклад: NTPsec и многое другое

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

NTPsec — безопасная версия NTP-демона (Network Time Protocol), на котором держится синхронизация времени в интернете. Проект начат в 2014 году как ответ на серию уязвимостей в классической реализации NTP. Реймонд — один из его основных мейнтейнеров.
GPSD — демон для работы с GPS-устройствами в Linux. Используется в навигационных приложениях, на автономных дронах, в робототехнике.
Reposurgeon — инструмент для миграции репозиториев между системами контроля версий (CVS → Subversion → Git и так далее). Реймонд использовал его для миграции огромного количества старых проектов, включая исторический архив самого GCC (миграция из SVN в Git в 2020 году — отдельная эпопея).
giflib — библиотека для работы с GIF-форматом. Поддерживается с 1989 года.
doclifter — конвертер из troff (старый формат форматирования документов в UNIX) в DocBook XML.
The Lemmings Compendium — да, на досуге Реймонд написал гайд по легендарной игре Lemmings 1991 года. Это очень в его стиле.

То есть это действующий программист, а не «бывший разраб», как многие из идеологов open source. В 2026 году ему исполнилось 68 лет, и он по-прежнему активно пишет код, обычно — низкоуровневые системные утилиты на C.

11. Политика, оружие и блог «Armed and Dangerous»

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

Реймонд — анархо-либертарианец: убеждённый сторонник минимального государства, права на частное оружие, свободного рынка как универсального инструмента. Он несколько десятилетий ведёт блог «Armed and Dangerous» («Вооружён и опасен») с подзаголовком «Sex, software, politics, and firearms» — «секс, программы, политика и огнестрельное оружие». В блоге он публикует длинные эссе на все четыре заявленные темы и собирает иногда сотни комментариев.

Это уже не та «нейтральная» интеллектуальная позиция, которая допустима в любой компании. Реймонд — публичный политический активист, и его позиции часто провоцируют резкую реакцию в хакерском сообществе, которое в последние пятнадцать лет сместилось в сторону левой повестки. Его оценки войн, феминизма, расовых вопросов многократно становились причиной скандалов. Он считает, что Запад находится в культурной войне с собственной академической левой интеллигенцией, что политкорректность в технологическом сообществе разрушает меритократию, что движения вроде Black Lives Matter — продукт марксистской манипуляции.

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

Он также сертифицированный мастер тхэквондо (чёрный пояс), увлекается фехтованием, играет на нескольких музыкальных инструментах (в основном на флейте), активен в субкультуре filk — фолк-музыки фантастического и фэндомного сообщества. Религиозно он определяет себя как нео-язычника.

Всё это необычно даже по меркам хакерского сообщества, в котором эксцентричных людей всегда хватало. Реймонд же эксцентричен даже на фоне самых эксцентричных.

12. 2020 год: исключение из OSI

В феврале 2020 года Реймонд оказался в центре нового скандала. Поводом стала его реакция на Ethical Source Definition — попытку группы активистов разработать новые лицензии для программного обеспечения, которые бы запрещали его использование в целях, противоречащих этическим принципам авторов (например, для военных или для систем массового слежения).

Реймонд выступил против этой инициативы — он считал её попыткой подорвать сам принцип open source, который по определению не делит пользователей на «хороших» и «плохих». Но проблема была не в позиции, а в форме. В письмах на рассылке License-Discuss (24 и 26 февраля 2020) Реймонд назвал автора инициативы «токсичной поехавшей» (toxic loonytoon), охарактеризовал происходящее как «политическое крысиное еблево» (political ratfucking), «вульгарный марксизм» и попытку «посадить политических комиссаров на каждый open-source-проект».

28 февраля 2020 года Памела Честек, председатель совета OSI, объявила об исключении Реймонда из рассылок License-Review и License-Discuss за нарушение Code of Conduct. В обосновании говорилось: его сообщения «оскорбительны, намеренно сеют раскол, неуважительны».

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

Реймонд ответил постом в своём блоге под названием «The Right To Be Rude» — «Право быть грубым». Суть позиции: открытое программное обеспечение всегда стояло на свободе слова, в том числе на свободе говорить грубо; превращение OSI в институцию с Code of Conduct, по его мнению, означает её смерть как движения. Многие с ним согласились. Многие категорически нет.

Это была горькая ирония. Человек, который придумал термин open source (формально — Кристин Петерсон, но Реймонд был главным его евангелистом), оказался изгнан из главной институции, посвящённой этому термину. Реймонд воспринял это как личное предательство и с тех пор резко критикует OSI.

13. Финал: библиотекарь, евангелист и баррикадный полемист

Что в итоге сделал Реймонд для нашей профессии?

Он систематизировал хакерскую культуру. The Jargon File и The New Hacker’s Dictionary — это, в каком-то смысле, наша устная история, превращённая в письменную. Без этой работы мы бы потеряли значительную часть фольклора лабораторий MIT и Stanford.

Он дал индустрии язык, на котором можно говорить о свободном программном обеспечении без испуга. «The Cathedral and the Bazaar» сделал больше для популяризации Linux в корпоративной среде, чем сотни маркетинговых кампаний. Open Source Initiative и сам термин «open source» — прямое следствие.

Он написал тексты, которые молодые программисты читают до сих пор. «How to Become a Hacker» — точка входа в хакерскую культуру для нескольких поколений. «The Art of Unix Programming» — манифест системного мышления.

Он продолжает писать код в свои 68 лет, и этот код используется в производственных системах по всему миру (NTPsec, GPSD, fetchmail).

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

Я склонен относиться к Реймонду так же, как к Столлману: отделять вклад от личных качеств. The Jargon File написан. Эссе «Собор и базар» прочитано миллионами и реально повлияло на индустрию. Термин «open source» прижился — и для лучшего, и для худшего. Эти результаты есть, и они никуда не исчезнут от того, насколько неприятно Реймонд иногда выражается в комментариях.

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

Главное про Реймонда, как мне кажется, состоит вот в чём: он создал словарь слов, которые мы до сих пор используем. Слова «open source», «hacker» в современном смысле, «bazaar model», «given enough eyeballs» — мы повторяем эти выражения каждый день, часто не зная, откуда они. Это словарь конца XX века, и он принадлежит Реймонду в той же мере, в какой словарь свободного ПО принадлежит Столлману, а словарь информатики как науки — Дональду Кнуту.

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

В следующих постах я планирую вернуться к технике — к парсингу, к компиляторам, к более конкретным инженерным темам. Биографическая серия про Шеннона, Столлмана, Emacs, Lisp и Реймонда на этом закрывается. Если в её процессе у вас возникло ощущение, что хакерская культура XX века — это что-то цельное, имеющее своих святых, своих еретиков, свои священные тексты и свои внутренние войны, — значит, серия удалась.

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

Главные тексты Реймонда

«The Cathedral and the Bazaar» — оригинальное эссе, 1997. Читается за час, после этого многое в индустрии становится понятнее.
«How to Become a Hacker» — эссе, 1996, регулярно обновляется. Самая известная точка входа в хакерскую культуру.
«Homesteading the Noosphere» — эссе о социальных нормах разработки open source.
«The Magic Cauldron» — экономика свободного программного обеспечения.
«The Art of Unix Programming» — книга, 2003. Полностью доступна онлайн.
The Jargon File — текущая версия словаря хакерского жаргона.

Об открытии исходников Netscape

«How I coined the term ‘open source’» — Кристин Петерсон рассказывает историю термина из первых рук.
История OSI — официальная летопись Open Source Initiative.
«Free as in Freedom» — биография Столлмана от Сэма Уильямса, в которой описан и Реймонд.

Споры и контекст

«Open Source Misses the Point of Free Software» — главное эссе Столлмана о том, почему термин «open source» он отказывается принимать.
«The Right To Be Rude» — пост Реймонда после исключения из рассылок OSI в 2020-м.

Биография

Eric S. Raymond — Wikipedia — самая полная биографическая статья на английском.
Личный сайт catb.org — там же все его эссе, программы и блог-указатели.
Блог «Armed and Dangerous» — собственный блог Реймонда.

Видео

📺 «The Cathedral and the Bazaar» — аудиокнига Реймонда

📺 Eric S. Raymond: Interview on Open Source Software

Lisp: язык, которому 68 лет и который до сих пор подсказывает будущее

2026-05-30T15:17:21.455Z

Осенью 1958 года математик Джон Маккарти приходит в Массачусетский технологический институт и начинает работу над языком, на котором можно было бы выразить рассуждения об «искусственном интеллекте» (термин, кстати, тоже его). Маккарти набрасывает математическую нотацию — формальное описание того, как вычислять символьные выражения с помощью функций. Эта нотация задумывалась как теоретический инструмент, не как настоящий язык программирования. Маккарти даже не собирался её реализовывать в коде. Для практических вычислений у него планировался другой, более «нормальный» синтаксис.

Тогда его аспирант, Стив Расселл, посмотрел на ту самую теоретическую функцию eval — фактически универсальный интерпретатор языка, выписанный на доске в виде математических уравнений, сказал, что её можно просто вручную перевести в машинный код IBM 704 и сделал это. К весне 1959-го у Расселла работал первый интерпретатор LISP, написанный целиком в кодах (тогда название ещё писалось капсом — как честная аббревиатура от LISt Processor). Маккарти потом будет вспоминать, что сам считал свою функцию eval чисто теоретической и был удивлён, когда Расселл превратил её в работающий код.

Этот момент — реализация теоретической математической нотации как настоящего языка — оказался одной из самых счастливых случайностей в истории нашей профессии. Lisp с этого дня живёт и развивается, ему исполняется 68 лет в 2026 году, и он по-прежнему остаётся одним из самых выразительных и идейно насыщенных языков программирования из существующих. На Lisp написан почти весь мир Emacs (через его диалект Emacs Lisp). На потомке Lisp — Clojure — написана значительная часть бэкендов многих современных интернет-компаний (Nubank, Walmart, Atlassian, Cisco). Уже семь поколений языков программирования учатся у Lisp, иногда сознательно копируя его конструкции, а иногда переоткрывая их под новыми именами.

Этот пост — об удивительной истории языка, идеи которого опередили эпоху на десятилетия и до сих пор не до конца догнаны. Я расскажу, откуда взялись скобки, S-выражения и car/cdr. Покажу, как Lisp подарил программированию сборку мусора, замыкания, функции первого класса, динамическую типизацию, рекурсию, метапрограммирование через макросы и REPL — то есть половину того, что мы сегодня считаем «современным». Доберусь до Лисп-машин и эпохи компании Symbolics, до раскола Maclisp/Interlisp и последующей стандартизации Common Lisp. Расскажу о Scheme и Clojure как двух самых живых его потомках. И покажу, почему десятый закон Гринспана — «всякая достаточно сложная программа на C или Fortran содержит спрятанную, медленную и плохо описанную реализацию половины Common Lisp» — до сих пор оказывается жестокой правдой о большинстве крупных проектов.

И, конечно, в финале — несколько слов о том, почему Lisp по-прежнему стоит изучать в 2026 году, даже если вы никогда не напишете на нём ни строчки продакшен-кода.

Маленькое замечание о написании

В этом тексте я последовательно пишу «Lisp» — с заглавной только первой буквой, как обычное имя собственное. Это современная конвенция, но она появилась не сразу.

Первые двадцать пять лет название писалось исключительно капсом — LISP. Это была аббревиатура от LISt Processor («обработчик списков»), и так её тогда и набирали — в статье Маккарти 1960 года, на обложках первых учебников, в академических работах 1960–70-х. Если открыть оригинальные исходники из MIT AI Lab, на каждой второй странице вы увидите «LISP» большими буквами.

Перелом случился в середине 1980-х, в момент стандартизации Common Lisp. Книга Гая Стила «Common Lisp the Language» (1984) уже последовательно использует «Lisp» как обычное имя, и всё сообщество перешло на такой вариант написания. Та же история произошла с другими старыми акронимами: FORTRAN превратился в Fortran, COBOL — в Cobol, BASIC — в Basic. Когда язык живёт достаточно долго и становится привычным культурным объектом, расшифровка аббревиатуры перестаёт быть актуальной, и капс уходит сам собой.

Это, кстати, неплохой исторический индикатор. Если вам сегодня попадается текст, где написано «LISP» большими буквами, — это с большой вероятностью либо историческая работа о Маккарти и эпохе MIT AI Lab, либо текст, написанный до середины 1980-х, либо стилизация под старину. Современные сайты Common Lisp, Scheme, Clojure, Racket — все пишут «Lisp». Так же делает Пол Грэм в эссе, Википедия в статьях, и стандарт ANSI X3.226-1994 в официальном тексте.

В этом посте я оставляю «LISP» только там, где специально говорю о первой реализации Маккарти и Расселла или цитирую старые работы. Всё остальное — «Lisp». В цитируемой ниже книге Герберта Стояна, например, в названии сохранён исторический капс — потому что это её настоящее, оригинальное название.

1. Маккарти, MIT и проект искусственного интеллекта

К 1958 году Джон Маккарти уже был известен. Он закончил аспирантуру в Принстоне у Соломона Лефшеца. Преподавал в Дартмуте, где летом 1956 года провёл легендарную Дартмутскую конференцию — двухмесячный семинар, на котором впервые прозвучал термин «искусственный интеллект» («artificial intelligence»), и который сейчас считается формальной точкой рождения области ИИ как самостоятельной дисциплины. Через два года Маккарти перешёл в MIT — там вместе с Марвином Минским создавал группу, которая в 1959-м официально стала MIT AI Lab.

Перед группой стояла задача: научить машину рассуждать. Что значит «рассуждать», точно никто не знал, но было понятно, что ничего похожего на привычные тогда языки программирования типа Fortran (1957) или COBOL (1959) для этой задачи не подойдёт. Fortran хорошо считал арифметические формулы, но не умел работать с тем, что Маккарти называл символьными выражениями — сложными иерархическими структурами вроде «функция от двух функций, первая из которых возвращает список троек».

Маккарти начал придумывать новый язык. Его конструкции были позаимствованы из лямбда-исчисления Алонзо Чёрча (1936), но с некоторыми существенными отличиями. От Чёрча — идея, что функция и её аргументы могут быть единообразно записаны как выражения, и что функция тоже может быть значением, передаваемым в другую функцию. От самого Маккарти — идея, что программу удобно записывать в виде той же самой структуры данных, с которой эта программа работает.

Эту идею потом назовут гомоиконичностью — «однородностью представления» (от греческого homo «одинаковый» + icon «образ»). На практике она означает, что программа на Lisp — это просто Lisp-список. Список вида (+ 1 2) — одновременно и данные (список из трёх элементов), и программа («применить операцию + к 1 и 2»). Эта простая на вид симметрия и есть та точка, из которой выросло почти всё, чем Lisp отличается от других языков.

2. S-выражения и их странные скобки

Маккарти изначально планировал два синтаксиса для своего языка. Один — для людей: близкий к привычной математической записи, с инфиксными операторами, более-менее естественный. Этот синтаксис он назвал M-expressions (Meta-expressions). Другой — для машины: упрощённый, единообразный, основанный на списках. Этот второй вариант — S-expressions (Symbolic expressions) — должен был быть всего лишь промежуточным представлением, в которое транслируется человеческий синтаксис перед исполнением.

Произошло, однако, обратное. Когда Стив Расселл реализовал интерпретатор, он принимал на вход именно S-выражения. Маккарти и его студенты, в ожидании пока кто-нибудь напишет транслятор из M в S, начали программировать прямо в S-выражениях. И обнаружили, что им так удобнее. Транслятор M-expressions, насколько известно, никогда не был доделан. S-выражения остались, M-выражения умерли.

Так Lisp получил свой знаменитый синтаксис из вложенных скобок. Программа вида:

(defun факториал (n)
  (if (= n 0)
      1
      (* n (факториал (- n 1)))))

— это просто список из четырёх элементов: символа defun, символа факториал, списка параметров (n) и тела функции (которое само является списком). И это тело, в свою очередь, — список из четырёх элементов: символа if, проверочного выражения (= n 0), ветки «тогда» 1 и ветки «иначе» (* n (факториал (- n 1))).

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

Когда программисты других языков впервые сталкиваются с этим водопадом скобок, у них обычно случается шок. Парижская акронимная шутка: Lisp расшифровывается как Lots of Irritating Silly Parentheses — «много раздражающих идиотских скобок». Шутка как шутка, но если вы посидите в Lisp хотя бы полчаса, скобки перестают раздражать: они начинают служить отступами и подсветкой структуры одновременно. Современные редакторы (Paredit и Parinfer в Emacs, vim-sexp в Vim, structural editing в большинстве IDE) делают навигацию по этому дереву совершенно естественной — вы оперируете не отдельными символами, а целыми выражениями.

3. CAR, CDR и наследство IBM 704

Список в Lisp реализован через связанные пары (cons-ячейки). Пара состоит из двух полей: первое поле хранит элемент, второе — указатель на остаток списка (тоже пару, или специальное значение «пустой список»). Это та же самая структура данных, которая теперь известна как связный список, но в Lisp она появилась практически на старте и стала основной.

Чтобы достать первый элемент пары, нужна была функция. Маккарти и его студенты назвали её car. Чтобы достать второе поле — функция cdr (произносится «коудер»). Эти странные имена не были придуманы для красоты — они остались от ассемблера IBM 704.

IBM 704 был построен на 36-битных машинных словах. Каждое слово делилось на несколько полей, и два самых частых поля назывались address part и decrement part. Соответствующие машинные инструкции для извлечения этих полей звались CAR (Contents of Address part of Register) и CDR (Contents of Decrement part of Register). Когда Расселл реализовывал cons-ячейку, он естественным образом разместил два её поля в этих двух частях машинного слова. И функции назывались по своим машинным инструкциям.

К 1962 году машины IBM 704 ушли в прошлое. К 1985-му даже их потомки исчезли из вычислительных центров. К 2026-му никто, кроме историков, не помнит, что значили эти аббревиатуры. А car и cdr остались — в Common Lisp, в Scheme, в Clojure (как first и rest, но традиционные имена тоже работают), в Emacs Lisp, в Racket. Это самая стойкая в истории программирования метка той аппаратной эпохи: машины давно нет, а названия функций используются каждый день.

Связанные пары в Lisp записываются точечной нотацией: (1 . 2) — это пара, где car = 1 и cdr = 2. Список (1 2 3) — на самом деле сокращение для (1 . (2 . (3 . nil))) — три вложенных пары, заканчивающиеся пустым списком. Список — частный случай пары, у которой в cdr тоже сидит список. Эта мелочь даёт огромную гибкость: пары можно соединять в деревья, графы, ассоциативные массивы, очереди — что угодно. Одна базовая структура, бесконечное количество применений.

4. Сборка мусора как побочный эффект

В 1959 году, во время реализации LISP, Маккарти столкнулся с проблемой, которой раньше никто не сталкивался: как освобождать память от cons-ячеек, которые больше не нужны.

В Fortran и языках того времени памяти было мало, и она распределялась статически: программист заранее объявлял все массивы и переменные, и операционная система выделяла под них фиксированные участки. В Lisp это не работало. Программа в любой момент могла создать новую cons-ячейку, например, при чтении S-выражения с входа. И в любой момент могла прекратить использовать какую-нибудь старую ячейку, оставив её болтаться без ссылок. Если эти неиспользуемые ячейки не освобождать, память кончится за несколько секунд работы интерпретатора. Если требовать от программиста явного освобождения (как потом будет в C через free), вся прелесть Lisp уходит: программист отвлекается на бухгалтерию памяти вместо того, чтобы думать о задаче.

Маккарти изобрёл то, что мы сегодня называем сборкой мусора (garbage collection). Идея была простая: время от времени интерпретатор останавливается, проходит по всем активным cons-ячейкам, помечает достижимые из «корней» (переменных и стека) как живые, а недостижимые объявляет мёртвыми и возвращает в пул свободной памяти. Так появился алгоритм mark-and-sweep, который до сих пор является основой большинства реализаций сборки мусора.

Сегодня сборка мусора есть почти везде — в Java, в Python, в Go, в Ruby, в JavaScript, в C# и в десятках других языков. Для нескольких поколений программистов это просто естественное свойство языка. Но придумал это в 1959 году Маккарти, как побочный эффект реализации Lisp. Если бы Lisp не появился, идея сборки мусора могла бы запоздать на десятилетия.

Я, кстати, про сборку мусора уже писал отдельный пост — там разобраны современные подходы (поколенческая, инкрементальная, конкурентная сборка) и почему она до сих пор остаётся областью активных исследований. Но база всего этого — Маккарти и его проблема с cons-ячейками.

5. 1960: знаменитая статья

В апреле 1960 года Маккарти опубликовал в Communications of the ACM статью с длинным названием «Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I». Это — формальная декларация Lisp как языка.

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

S-выражения и пары;
семь базовых операторов (atom, eq, car, cdr, cons, quote, cond);
лямбда-выражения как способ задавать функции;
условное выражение cond;
рекурсию как основной механизм вычисления;
функцию eval, которая принимает на вход Lisp-программу как S-выражение и интерпретирует её.

Эти семь операторов плюс eval — то самое, из чего собирается весь язык. Пол Грэм в своей классической статье «The Roots of Lisp» (2002) подробно реконструирует, как из этих кирпичей складывается всё, что нужно для серьёзного программирования. Грэм показывает, что Маккарти в 1960-м фактически собрал минимальный набор примитивов, эквивалентный машине Тьюринга, и собрал так удачно, что многие современные языки до сих пор основаны на тех же идеях, только в другом синтаксисе.

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

6. 1962: первый компилятор

Интерпретатор Расселла был отличной демонстрацией, но работал медленно. Каждая операция требовала прохода по дереву S-выражения, разбора, диспетчеризации. Для серьёзных программ это не годилось.

В 1962 году Тим Харт и Майк Левин в MIT AI Lab написали первый компилятор Lisp — программу, которая принимала Lisp-функцию и выдавала машинный код. Компилятор был написан на самом Lisp, что само по себе было концептуальным прорывом. Это и есть тот трюк, который позже назовут раскруткой компилятора (англ. bootstrapping) — устоявшийся термин из учебников по теории трансляции (у Свердлова, в русском переводе Вирта): компилятор языка, написанный на самом этом языке, способен компилировать сам себя, и дальше развивается независимо от исходного представления.

Компиляция Lisp оказалась удивительно эффективной. Откомпилированная функция работала в 40 раз быстрее интерпретированной. С этого момента Lisp перестал быть «медленным языком» и стал инструментом, на котором можно писать серьёзные системы.

С появлением компилятора Lisp получил то, что мы сегодня считаем само собой разумеющимся: возможность запустить REPL (read-eval-print loop), где можно интерактивно вводить выражения, тут же исполнять их, видеть результат, тут же определять новые функции, и всё это в одной живой сессии. REPL — изобретение Lisp, появившееся ещё в 1960-х. Все современные интерактивные оболочки — IPython, Node.js, Julia, Erlang shell — наследники этого подхода.

7. Множественные Лиспы: Maclisp, Interlisp, и кембрийский взрыв

С 1962 по 1980 годы Lisp пережил период бурного размножения. Это было неизбежно: язык легко переписывался под новое железо (нужно было реализовать всего семь примитивов и eval), сообщество было небольшим и распределённым, а централизованной стандартизации в эпоху ARPANET ещё не существовало.

Появились (не претендую на полноту списка):

Maclisp (1966) — разработан в MIT в рамках Project MAC (отсюда название). На нём в 1968-м была написана знаменитая система компьютерной алгебры Macsyma — одна из первых программ для символьных математических вычислений, которая работает до сих пор как Maxima. Macsyma была настолько мощной для своего времени, что NASA её использовало для аналитических расчётов траекторий. На Maclisp работал ранний интерпретатор Emacs Эмерсона Голдсмита.

Interlisp (1966) — разработан в BBN, потом продолжен в Xerox PARC. Был знаменит своей интерактивной средой разработки: структурный редактор, отладчик, профайлер — всё то, что сегодня считается базовым набором IDE. Многие идеи Interlisp потом перекочевали в Smalltalk и оттуда — в современные среды разработки.

Franz Lisp (1978) — диалект для UNIX-машин, разработан в Беркли. Был популярен в начале 1980-х как доступный Lisp для академических кругов.

Scheme (1975) — об этом отдельный разговор ниже.

Standard Lisp (1969), MDL (1971), NIL (1979), T (1982), Le Lisp (1981), EuLisp (1990) — список можно продолжать.

К началу 1980-х было больше десяти серьёзных диалектов Lisp, и они были несовместимы между собой. Программу с Maclisp нельзя было запустить на Interlisp без переписывания.

8. Лисп-машины

Параллельно с программными диалектами происходила ещё одна удивительная вещь: для Lisp стали проектировать собственное железо.

Идея появилась в начале 1970-х в MIT AI Lab. Lisp-программы предъявляли к компьютеру специфические требования: динамическая типизация (значит, нужно проверять типы во время исполнения), сборка мусора (значит, нужно эффективно ходить по памяти), глубокая рекурсия (значит, нужен большой стек), интенсивная работа с указателями. Универсальные процессоры того времени делали всё это медленно. Возникла идея сделать процессор, изначально заточенный под Lisp.

В 1973 году Том Найт и Ричард Гринблат в MIT построили CONS Machine — первый прототип. В 1978-м появилась её улучшенная версия — CADR (название от Lisp-функции cadr, которая возвращает второй элемент списка, что является шуткой над тем, что это «вторая версия» машины). К началу 1980-х из MIT AI Lab выделились две коммерческие компании:

Lisp Machines Inc. (LMI) — основана в 1979 году группой во главе с Ричардом Гринблатом, с философией ближе к традиционному «хакерскому» подходу.

Symbolics — основана тогда же, в 1980 году, под руководством Расселла Нофтскера, с более бизнес-ориентированным подходом и желанием сделать Лисп-машину коммерческим продуктом для крупных корпоративных заказчиков.

Эти две компании раскололи MIT AI Lab пополам, и это стало одной из главных личных трагедий Ричарда Столлмана и одним из ключевых эпизодов, приведших его к идее свободного программного обеспечения. Расселл Нофтскер из Symbolics нанял большую часть сотрудников AI Lab, оставив лабораторию опустевшей. Столлман, оставшись практически один, в одиночку переписывал на стороне MIT всё, что выпускала Symbolics, чтобы у LMI был доступ к улучшениям. Это противостояние длилось два года и закончилось его уходом из MIT в 1984-м с проектом GNU.

Symbolics и LMI в течение 1980-х выпускали впечатляющие машины: Symbolics 3600, TI Explorer (от Texas Instruments), MacIvory (плата для Macintosh). На этих машинах работало то, что и сегодня кажется фантастикой: полноценная объектно-ориентированная среда разработки с динамической отладкой, средствами рефакторинга, инспектором объектов прямо в живой системе. Графический интерфейс, в котором каждое окно знало, какой объект оно отображает, и позволяло вызвать на этом объекте любую функцию через меню. По уровню инструментов разработки Лисп-машины 1985 года были на десять лет впереди всего остального, и в каком-то смысле до сих пор непобеждёнными.

Но рынок Лисп-машин рухнул. К 1990-му обычные рабочие станции (Sun SPARC, MIPS, Intel 386) стали достаточно мощными, чтобы Lisp бегал на них быстрее, чем на специализированном железе. Symbolics обанкротилась в 1996-м (формально дотянула до 2010-х в виде маленькой компании, поддерживающей старые системы). LMI закрылась ещё раньше. AI winter — кризис в исследованиях искусственного интеллекта конца 1980-х — добил остатки этого мира.

С Лисп-машинами умерла целая эпоха программистской культуры. Это, наверное, самая большая утрата в истории нашей профессии. Несколько поколений программистов жили в среде, в которой код был не файлом, который ты редактируешь и потом перекомпилируешь, а живой системой, в которой ты в любой момент мог переопределить любую функцию, увидеть результат, откатить, попробовать другую. И эта среда исчезла. Сейчас Emacs — последнее живое наследие той эпохи: примерно так же ощущается работа в Lisp-машине, только без графического богатства Symbolics.

9. 1984: Common Lisp и попытка примирения

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

С 1981 по 1984 годы группа главных архитекторов Lisp — Гай Стил (тот самый, что писал с Столлманом первый Emacs, а также соавтор Scheme и Java), Скотт Фалман (Carnegie Mellon, автор CMU Common Lisp и заодно изобретатель смайлика :-) в 1982-м), Дэниел Уайнреб (MIT, Symbolics), Дэвид Мун (Symbolics) и другие — заняли долгие переговоры о том, как объединить все основные идеи Maclisp, Lisp Machine Lisp, Spice Lisp, NIL, S-1 Lisp в единый стандарт.

Результат вышел в 1984 году в виде книги Гая Стила «Common Lisp the Language», которую все обычно зовут CLtL. Это была первая (и тогда — единственная) спецификация Common Lisp. В 1990-м вышло второе, существенно расширенное издание (CLtL2), которое описывало уже мощный, зрелый язык с CLOS — Common Lisp Object System.

В 1994-м Common Lisp получил официальный стандарт ANSI X3.226-1994 — один из крупнейших стандартов на язык программирования по объёму спецификации (около 1100 страниц). С тех пор стандарт не менялся ни разу. Это намеренно: Common Lisp в текущем виде считается «законченным» языком, и развитие идёт через библиотеки, а не через ядро.

CLOS — Common Lisp Object System — заслуживает отдельного упоминания. Это система объектного программирования, разработанная в первую очередь Грегором Кичалесом, Дэниелом Бобровом, Линдой ДеМайкл и Джимом Розом в середине 1980-х. CLOS впервые предложил множественное наследование с алгоритмически детерминированным разрешением (через так называемый C3-алгоритм), множественную диспетчеризацию (метод вызывается не по типу одного «себя», а по типам сразу нескольких аргументов) и систему мета-объектов (MOP), позволяющую программистам менять саму работу системы объектов из кода программы. Эти идеи в большинстве своём до сих пор не реализованы в основных мейнстримных языках. Java и C# до сих пор не имеют множественной диспетчеризации. Python научился чему-то похожему через functools.singledispatch только в 2014-м.

Грегор Кичалес из той же команды CLOS позже изобрёл аспектно-ориентированное программирование в Xerox PARC и стал автором языка AspectJ — что, опять же, корнями уходит в идеи MOP из Common Lisp.

10. Scheme: минимализм и его последствия

Параллельно Common Lisp, в 1975 году в MIT появился совсем другой диалект Lisp — Scheme. Его авторы — Гай Стил и Джеральд Сассмен — задумывали Scheme как минималистичную, академически чистую альтернативу. Там, где Common Lisp шёл по пути «возьмём всё хорошее и положим в коробку», Scheme шёл по пути «оставим только самое необходимое, всё остальное можно собрать поверх».

Scheme стал, наверное, самым важным диалектом Lisp с точки зрения влияния на теорию программирования. На Scheme построены примеры в знаменитой книге «Structure and Interpretation of Computer Programs» (SICP) — учебнике, по которому в MIT в 1980–90-х учили первокурсников программированию. SICP считается одной из лучших книг по программированию в истории. Она не учит конкретному языку — она учит, что такое вычисление как процесс, как программы становятся данными, и наоборот. Если вы прочли SICP, ваше отношение к программированию меняется навсегда.

Scheme принёс в Lisp-мир и в программирование вообще несколько важных идей:

Продолжения первого класса (англ. first-class continuations, оператор call/cc) — возможность взять «остаток вычисления» как объект и передать его дальше. Из call/cc выросло понимание управления потоком как обычных значений, что потом превратилось в современные async/await, генераторы, корутины.

Лексическая область видимости как стандарт. До Scheme многие диалекты Lisp использовали динамическую область видимости (переменная видна везде, где функция вызывается). Scheme сделал лексическую область (переменная видна только там, где она определена) основой языка. Все современные языки программирования теперь следуют именно этой модели.

Хвостовая рекурсия как обязательное требование к реализации. В Scheme рекурсивная функция, последним действием которой является вызов самой себя, не создаёт нового стекового кадра, а преобразуется в цикл. Это означало, что в Scheme можно было программировать чисто функционально, без явных циклов, не боясь переполнения стека.

Scheme получил два главных стандарта: серию RnRS (Revisedⁿ Report on the Algorithmic Language Scheme), от R5RS (1998) через R6RS (2007) к R7RS (2013). R5RS — самый минималистичный из них, помещается на пятидесяти страницах. R6RS — попытка добавить «промышленных» удобств, которая вызвала раскол в сообществе. R7RS — компромиссная версия.

Из академических потомков Scheme — Racket, который используется как язык для исследований в области создания языков программирования и для обучения. На Racket написан Pollen — язык для верстки книг, на нём же написана большая часть DrRacket — IDE, которая используется во множестве университетских курсов.

Из Scheme же произошёл Guile — встроенный язык расширения GNU-проектов. На Guile написаны конфигурации многих утилит GNU; на Guile написана операционная система GNU Guix (пакетный менеджер и дистрибутив Linux, в котором сами пакеты описаны как Scheme-программы).

11. Clojure: Lisp, который полюбила промышленность

В 2007 году Рич Хики — независимый разработчик, до этого 15 лет писавший на Common Lisp и C++ для коммерческих заказчиков — выложил в открытый доступ свой новый диалект Lisp под названием Clojure. Это была первая за десятилетия серьёзная попытка сделать Lisp, который смогли бы массово полюбить в индустрии.

Хики работал над Clojure в одиночку два с половиной года. Его собственная мотивация была простой: ему хотелось писать на Lisp, но он понимал, что без доступа к огромной экосистеме библиотек Common Lisp проигрывает Java и .NET. Хики решил встроить Lisp в JVM — взять синтаксис и идеи Lisp, но скомпилировать его так, чтобы он напрямую запускался на виртуальной машине Java и мог использовать любую Java-библиотеку без обёрток.

Эта идея оказалась удачной. Внезапно Clojure-программисты получили доступ ко всему экосистеме Java: HTTP-сервера, базы данных, очереди, веб-фреймворки — всё это стало доступно через простой вызов из Lisp-кода. В обратную сторону тоже работало: Java-разработчики могли встраивать Clojure-код в свои проекты постепенно, не переписывая всё.

К тому же Хики добавил несколько идей, которых не было в традиционном Lisp:

Иммутабельные структуры данных по умолчанию. В Clojure список, вектор, хеш-таблица не модифицируются. Если вы хотите добавить элемент в вектор, вы получаете новый вектор, а старый остаётся как был. Это сделано через persistent data structures — структуры, которые делают эффективное копирование с разделением (структуры с общими «хвостами» делят память). Идея заимствована из работ Криса Окасаки (его книга Purely Functional Data Structures 1998 года). Эта неизменяемость даёт огромный выигрыш в многопоточном программировании: если данные нельзя изменить, не нужно беспокоиться о гонках.

Software Transactional Memory (STM) — модель управления состоянием через транзакции, как в базах данных. Хочется поменять переменную? Заверни в транзакцию. Хочется поменять две связанные переменные согласованно? Тоже в транзакцию. Внутри одной транзакции изменения видны единым атомарным шагом. Это сильно проще для понимания, чем традиционные мьютексы и блокировки.

core.async — система каналов и горутин в стиле CSP (так же как в Go), реализованная как библиотека через макросы. То есть Clojure не нужно было встраивать корутины в ядро языка: их сделали поверх макросов, и они работают идентично нативным конструкциям.

ClojureScript — версия Clojure, компилируемая в JavaScript. Используется для написания фронтендов, часто в связке с библиотекой Reagent (обёртка над React).

Clojure быстро стал заметным в индустрии. Сегодня (2026 год) на нём пишут бэкенды Nubank (один из крупнейших цифровых банков Бразилии, на Clojure написана почти вся серверная часть), Walmart (e-commerce платформа), Apple, Atlassian, Cisco, CircleCI (на Clojure написан почти весь продукт), Funding Circle, Metabase (одна из главных open-source BI-платформ). Это, пожалуй, первый Lisp, на котором стало удобно писать обычный коммерческий код в обычной коммерческой компании без необходимости содержать команду из адептов.

Рич Хики в течение десяти лет читал доклады с базовыми идеями программирования, которые видны в Clojure: «Simple Made Easy» (2011, о разнице между «простым» и «знакомым»), «The Value of Values» (2012, об иммутабельных структурах данных), «Hammock-Driven Development» (2010, о роли времени и обдумывания в разработке). Эти доклады сегодня считаются обязательными к просмотру для любого инженера, который всерьёз задумывается о том, как устроена разработка софта и почему одни решения оказываются устойчивее других.

12. Десятый закон Гринспана и парадокс Lisp

В начале 1990-х американский программист Филип Гринспан сформулировал шуточный закон, который потом стал одним из самых цитируемых афоризмов о программировании:

Всякая достаточно сложная программа на C или Fortran содержит спрятанную, медленную, плохо документированную и плохо специфицированную реализацию половины Common Lisp.

Этот закон называется десятым законом Гринспана (хотя предыдущих девяти законов не существует — Гринспан пошутил и сразу сделал «десятый» как форма самопровозглашённой пословицы).

За шуткой стоит наблюдение, которое многократно подтверждалось. Возьмём любой крупный проект на C — Linux kernel, PostgreSQL, GCC, Git, nginx, любой большой коммерческий продукт. В каждом из них рано или поздно появляется:

собственная система конфигурации с псевдо-языком (а это интерпретатор);
собственный механизм событий и колбэков (а это асинхронное программирование первого класса);
собственная система плагинов с динамической загрузкой кода (а это динамическая типизация и eval);
собственный язык шаблонов или DSL для описания каких-то правил (а это макросистема);
собственная сборка мусора, обычно реализованная через reference counting или arenas (а это сборка мусора).

То есть программа на «низкоуровневом» языке постепенно отращивает в себе всё то, что в Lisp было с первого дня, — но в неполном, плохо специфицированном, ad hoc виде. Закон Гринспана — это сатира на эту неизбежность.

Современным языкам программирования (Python, JavaScript, Go, Rust, Swift, Kotlin) тоже потребовались десятилетия, чтобы аккуратно вернуть себе те конструкции, которые в Lisp были с 1960-го: лямбды, замыкания, функции первого класса, сборка мусора, динамическая типизация, REPL. Каждое появление одной из этих фич в новом мейнстримном языке воспринимается как «прорыв» — а программисты на Lisp в это время смотрят и грустно улыбаются.

Маленькое пояснение про «первый класс» — я этот термин несколько раз употреблял по ходу текста, но толком не расшифровал. Сущность в языке программирования называется первоклассной (англ. first-class), если её можно использовать так же свободно, как обычные данные: класть в переменную, передавать в функцию как аргумент, возвращать из функции, складывать в массив или словарь. Например, целое число 42 в любом языке — первоклассная сущность: его можно куда угодно передать и где угодно сохранить.

А вот функции в большинстве старых языков первоклассными не были. В Fortran или раннем C функция — это не значение, которое можно куда-то положить, а именованный кусок кода, который можно только вызвать. В Lisp с 1958 года всё иначе: функция — обычное значение, его можно записать в переменную, отдать другой функции, вернуть как результат. Из этого выросли map, filter, reduce, колбэки, обработчики событий, замыкания, декораторы — половина того, чем мы пользуемся сегодня. Когда в Java только в 2014 году (Java 8) добавили лямбды, это было запоздалое подтягивание к тому, что в Lisp работало с самого начала.

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

Понимание того, что в языке можно сделать первоклассным практически что угодно — функции, типы, синтаксис, управление потоком, целые предметные области — и есть то, ради чего стоит однажды всерьёз погрузиться в Lisp. Об этом, собственно, и знаменитая фраза Эрика Реймонда из эссе «How to Become a Hacker»:

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

Это одна из самых известных рекомендаций в нашей профессии. Я бы её повторил полностью: даже если вы никогда не напишете ничего серьёзного на Clojure или Common Lisp, проведите неделю с любым из них, разберите SICP до главы 4 (где авторы пишут на Scheme сам Scheme), пройдите Maccarthy’s eval своими руками. После этого многое в любом языке программирования начнёт казаться вам очевидным.

13. Гомоиконичность и макросы: главная сверхспособность

Я уже несколько раз упоминал, что программа на Lisp — это просто Lisp-список. А теперь объясню, что это даёт.

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

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

Это и есть макросы — функции, которые работают не во время исполнения, а во время компиляции: они принимают код, переписывают его в другой код, и уже этот другой код компилируется и исполняется. Макросы Lisp — это не текстовая подстановка, как макросы в C; это полноценное манипулирование деревьями. Внутри макроса вы используете весь язык, всю его мощь.

С помощью макросов можно встроить в Lisp практически любую языковую конструкцию, которую вы видели в других языках. Цикл for в стиле C? Несколько строк макроса. Декларативная маршрутизация HTTP-запросов как в Ruby on Rails? Несколько строк. Объявление компонента в стиле React? Несколько строк. SQL-запросы как первоклассные конструкции прямо в коде? Несколько строк (это реальная библиотека HoneySQL в Clojure).

Когда в Python в версии 3.10 (2021) появилось pattern matching, это было крупное событие — потребовался отдельный PEP, обсуждение длиной несколько лет, серьёзная работа над компилятором. В Lisp pattern matching — это просто библиотека, написанная любым желающим за пару дней с помощью макросов. Когда в JavaScript появился async/await, потребовалось встраивать новую конструкцию в стандарт ECMAScript. В Clojure async/await был сделан как библиотека core.async с помощью макросов.

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

Здесь, кстати, корень десятого закона Гринспана. Программы на других языках тоже отращивают свои мини-языки, но мучительно — через тонны boilerplate-кода (шаблонного, повторяющегося кода, который приходится писать руками снова и снова просто для того, чтобы обвязать друг с другом готовые куски). В Lisp это происходит естественно и почти без усилий.

14. Что в итоге выбрать в 2026 году

Если вы хотите попробовать Lisp в 2026 году, у вас есть несколько вариантов.

Clojure — самый практичный выбор. Если вы хотите писать на Lisp реальный продакшен-код, начинайте с него. Доступ ко всей JVM-экосистеме, развитое сообщество, активные обновления, хорошие инструменты разработки. Стартовая точка — официальный сайт и книга «Clojure for the Brave and True» Дэниела Хайгигагена (доступна онлайн бесплатно). Доступная среда разработки — Calva (плагин для VSCode) или CIDER (для Emacs).

Racket — если вы хотите учиться программированию или интересуетесь созданием языков. Великолепная IDE (DrRacket), отличная документация, огромный набор учебных материалов. SICP читается лучше всего именно на Racket. Если хотите изучать «How to Design Programs» — это тоже Racket.

SBCL (Steel Bank Common Lisp) — если хотите работать с классическим Common Lisp. Один из самых быстрых Lisp-компиляторов в мире, по производительности конкурирует с C. Среда разработки — Emacs + SLIME (или Sly). Книга для начала — «Practical Common Lisp» Питера Зайбеля (доступна онлайн бесплатно).

Emacs Lisp — если вы уже пользуетесь Emacs или собираетесь начать. Это не «универсальный» Lisp, а специализированный для редактирования. Но именно он сегодня — самый массово используемый Lisp-диалект в мире (благодаря миллионам активных пользователей Emacs).

Scheme через MIT/GNU Scheme или Chez Scheme — если вы хотите классический академический Scheme и работаете с SICP.

Hy — Lisp, компилируемый в Python AST. Любопытный гибрид: вы пишете S-выражения, но получаете доступ ко всем Python-библиотекам. Не для продакшена, но как способ попробовать Lisp, не отходя от Python — отличный.

Janet — современный минималистичный Lisp-вариант, написанный на C. Маленький, встраиваемый, без зависимостей.

Если же вы вообще не уверены, начинать ли — я бы рекомендовал прочитать хотя бы статью Пола Грэма «The Roots of Lisp» (33 страницы, читается за вечер). Грэм там показывает, как из семи примитивов Маккарти собирается вся машинерия Lisp, и одновременно — половина машинерии любого современного языка программирования. После этого Lisp перестаёт быть страшной и непонятной территорией.

15. Финал: язык, который продолжает учить

К 2026 году Lisp — это уже не модный, не «горячий» язык. На нём не делают стартапы для Y Combinator. О нём не говорят на каждой конференции. Поисковые запросы про Lisp стабильно низкие. Большинство современных программистов знают про него как про «что-то старое со скобками».

Но Lisp продолжает работать. На Clojure пишут банковские системы. На Emacs Lisp работает миллионы программистов. На Common Lisp до сих пор крутятся системы научной верстки, экспертные системы, инструменты для проектирования микросхем. На Scheme учат программированию в MIT, Брауне, Северо-Восточном университете. На Racket пишут новые языки программирования. На Guile живёт операционная система GNU Guix. Внутри Photoshop с конца 1980-х работал диалект AutoLisp (он же — внутри AutoCAD до сих пор); компьютерная алгебра Maxima — это потомок Macsyma — до сих пор использует Lisp под капотом. Это не язык, который умер. Это язык, который ушёл в инфраструктуру.

И главное — Lisp продолжает влиять. Каждое новое поколение языков программирования возвращается к чему-то, что в Lisp было с 1960-го. JavaScript получил функции первого класса. Python получил декораторы и pattern matching. Rust получил трейты и тип-классы (которые сами восходят к концепциям типизированных вариантов Lisp). Go получил горутины (которые соответствуют моделям параллелизма из EuLisp 1990 года). Каждый раз это представляется как новизна, и каждый раз Lisp-программисты тихо улыбаются.

Маккарти, придумавший Lisp в 1958 году, умер в 2011-м в возрасте 84 лет. Он успел увидеть Clojure, увидеть программистов всего мира, которые писали на нём системы, обрабатывающие миллионы транзакций. Сам Маккарти Lisp редко использовал в последние десятилетия жизни. Его интересы сместились в формальную логику и теорию знания — то есть в философию того, как человек что-то «знает» и как из этого знания делаются выводы. Но язык, который он придумал почти случайно, как побочный продукт работы по искусственному интеллекту, оказался одним из самых долгоживущих культурных артефактов нашей профессии.

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

Lisp — это, в каком-то смысле, главный аргумент в пользу того, что в программировании есть фундаментальные структуры, которые не зависят от моды, от железа, от языков. Маккарти их обнаружил. А мы их с тех пор продолжаем «изобретать» их заново под разными именами.

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

Главные тексты

John McCarthy, «Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I», CACM, 1960 — исходная статья.
Paul Graham, «The Roots of Lisp» (2002) — реконструкция Маккарти на современном языке. Обязательно к прочтению.
Paul Graham, «Revenge of the Nerds» (2002) — манифест о том, почему Lisp даёт преимущество в реальной разработке.
Paul Graham, «Beating the Averages» (2003) — как Lisp помог Виawebу обогнать конкурентов.

Книги

«Structure and Interpretation of Computer Programs» (SICP) — Гарольд Эйбельсон и Джеральд Сассмен. Одна из лучших книг про программирование вообще.
«Practical Common Lisp» — Питер Зайбель. Лучшая практическая книга про Common Lisp.
«Clojure for the Brave and True» — Дэниел Хайгигагена. Лучшая книга для входа в Clojure.
«On Lisp» — Пол Грэм. О макросах и продвинутом Lisp.
«Let Over Lambda» — Даг Хойт. Глубокое погружение в макросы Common Lisp.

Видео

📺 Rich Hickey, «Simple Made Easy» — программный доклад автора Clojure о разнице между «простым» и «знакомым».

📺 Rich Hickey, «The Value of Values» — об иммутабельности и о том, что значит ценить значения.

📺 Rich Hickey, «Hammock-Driven Development» — о роли обдумывания в разработке.

📺 «The Most Beautiful Program Ever Written» — рассказ о функции eval в Scheme.

Среды разработки и реализации

Clojure — основная страница.
Calva — Clojure-плагин для VSCode.
SBCL — главный современный Common Lisp.
Racket — Scheme-подобная платформа для создания языков.
MIT/GNU Scheme — классический Scheme.
GNU Guile — встраиваемый Scheme.

История

Herbert Stoyan, «LISP — History and Development» — академический обзор.
The History of Lisp by John McCarthy — рассказ самого Маккарти.
«The Evolution of Lisp» — Ричард Габриэль и Гай Стил, длинная история всех диалектов.
The Symbolics Story — история эпохи Лисп-машин.

Emacs: редактор, который думает, что он операционная система

2026-05-29T21:53:49.051Z

В 1976 году в Массачусетском технологическом институте двое программистов — Гай Стил и Ричард Столлман — сели за терминалы и начали писать макропакет для текстового редактора TECO. Параллельно, в трёх с половиной тысячах километров к западу, на территории Калифорнийского университета в Беркли, аспирант Билл Джой через слабый телефонный модем настраивал визуальный режим редактора ex, и его поделка вскоре получила имя vi.

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

Этот пост — об одном из этих двух инструментов, о Emacs. Я расскажу о его странном рождении из макросов чужого редактора и о невероятной живучести (полвека в строю и ноль признаков смерти). Покажу, как внутри него поселился Lisp-интерпретатор и почему отсюда родилась знаменитая шутка, что Emacs — это «прекрасная операционная система, в которой не хватает только хорошего текстового редактора». Доберусь до современных дистрибутивов вроде Doom Emacs и Spacemacs, благодаря которым в 2026 году в Emacs продолжают приходить молодые программисты. И, конечно, упомяну vi — без него в этой истории не обойтись, потому что Emacs во многом определяется именно через контраст с этим своим вечным соседом по индустрии.

Я не буду делать вид, что эта тема нейтральна. Любой человек, который всерьёз работал с любым из этих двух редакторов, имеет своё мнение, и его мнение, скорее всего, противоположно вашему. Я постараюсь отдать обоим должное и не воевать ни на чьей стороне. Хотя, признаюсь, к Emacs у меня личное уважение особое — за объём идей, которые в нём поместились. Однако сам я пока до использования Emacs не дорос и использую Neovim. Но мне очень любопытно, какой может стать моя жизнь, если я начну всерьёз работать в Emacs. Где бы только найти на всё время. Или несколько жизней.

1. 1976 год, MIT, и редактор по имени TECO

Чтобы понять, откуда взялся Emacs, вспомним, какие редакторы существовали до него и почему люди были ими недовольны.

Главный текстовый редактор Лаборатории искусственного интеллекта MIT в начале 1970-х назывался TECO — Text Editor and Corrector. Он был написан ещё в 1962 году для машины PDP-1, потом портирован на PDP-6 и PDP-10. К середине 1970-х TECO был старым, заслуженным, мощным и при этом совершенно нечитаемым редактором. Его команды представляли собой короткие шифры из пары символов. Составленная из этих команд программа могла выполнять сложные правки текста, но прочесть её постороннему человеку было сложно или даже невозможно. В хакерской культуре MIT была шутка про «TECO в стиле line noise», когда строчка команд выглядела буквально как помехи на телефонной линии.

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

К 1976 году в MIT AI Lab каждый продвинутый пользователь имел свой собственный набор макросов для TECO. У одного — для разметки текста. У другого — для работы с файлами кода на LISP. У третьего — для писем в ARPANET. Эти наборы получили названия — TECMAC, TMACS, RMODE, DOC, MACROS — каждый со своей логикой клавиш и своими привычками. Если в лабораторию заходил новый сотрудник и спрашивал «как мне отредактировать файл?», его первый ответ был «зависит от того, чьим набором ты хочешь пользоваться».

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

2. Стэнфорд 1976: визит и идея

В том же 1976 году Ричард Столлман съездил в Стэнфорд-AI-Lab — лабораторию искусственного интеллекта Стэнфордского университета. Там он увидел редактор по имени E, написанный Фредом Райтом, и был впечатлён. E работал в режиме, который сейчас мы называем WYSIWYG (What You See Is What You Get): когда вы нажимаете клавишу, изменение сразу появляется на экране, без необходимости вводить команду «обновить дисплей». TECO так работать не умел, его дисплейный режим был неполноценным.

Столлман вернулся в Кембридж с мыслью, что нужно сделать то же самое с TECO. И обнаружил, что у его коллеги по AI Lab по имени Карл Миккельсен уже был зачаток такого режима — модификация TECO под названием Control-R, в которой экран автоматически обновлялся после каждого нажатия клавиши. Столлман переписал этот код, чтобы он работал эффективнее, и добавил к нему поддержку макросов внутри display-режима: теперь любая клавиша могла быть переопределена так, чтобы запускать произвольную TECO-программу.

Это и был последний кирпичик. Гай Стил, ещё один хакер MIT AI Lab (тот самый Стил, который позже станет соавтором стандарта Common Lisp, спецификации Java и кучи другого), предложил Столлману объединить все циркулирующие в лаборатории макропакеты в один общий набор с симметричной системой клавиатурных сочетаний. Стил и Столлман сели за терминалы и за одну ночь написали базовый каркас: систему поиска и выполнения команд.

Через неделю Стил отошёл от проекта (вернулся к своим обязанностям), а Столлман уже один довёл его до готового состояния. К Новому 1977 году новый объединённый редактор уже теснил TECMAC и TMACS. Через год TECMAC и TMACS были полностью вытеснены.

Имя проекта — Emacs — расшифровывалось как Editor MACroS («макросы редактора»). По другой, апокрифической версии — в честь популярного в Бостоне магазина мороженого Emack & Bolio’s, который Столлман часто посещал, и в названии которого слышалось то же слово. Сам Столлман потом будет иронизировать на эту тему, но никогда не станет отрицать апокриф полностью.

В любом случае, к 1977 году в MIT появился новый стандарт редактирования текста — Emacs, написанный поверх TECO как набор макросов.

3. Множественные Имаксы: EINE, ZWEI, Gosling Emacs

С 1977 по 1984 годы Emacs пережил период бурного размножения. Когда исходный код у вас свободно доступен (а в MIT AI Lab он именно так и был доступен), и когда сам редактор написан в стиле «расширяй как хочешь», у людей мгновенно возникает желание сделать свою версию.

Появились EINE (рекурсивный акроним EINE Is Not EMACS, «EINE — это не EMACS») и ZWEI (ZWEI Was EINE Initially, «ZWEI был сначала EINE») — обе написаны Дэниелом Уайнребом и Майком Макмагоном для Lisp-машин. Они отличались тем, что были написаны на Zetalisp, а не на TECO. Из ZWEI потом вырастет Zmacs.

В Honeywell Bernard Гринберг написал MulticsEmacs в 1978 году — версию для операционной системы Multics. Он же первым реализовал значительную часть Emacs в Lisp, превратив его из редактора с макросами в полноценную Lisp-машину с текстовым интерфейсом.

В Bell Labs Джеймс Гослинг, тот самый, который позже создаст Java, написал Gosling Emacs, или gosmacs — реализацию на C для UNIX-систем. Гослинг впервые продал свой Emacs коммерчески (его лицензировала компания UniPress), и именно история с этой коммерциализацией позже окажется одним из формирующих моментов в политическом пути Столлмена.

К 1983-му в мире было около десятка различных программ под названием «Emacs», и было понятно, что нужна единая, по-настоящему свободная, версия, которая станет ядром нового открытого проекта.

4. 1984: GNU Emacs

В сентябре 1983 года Ричард Столлман объявил о начале работы над операционной системой GNU. Первой крупной программой в составе ОС стал GNU Emacs — переписанный с нуля свободный редактор на основе всех накопленных к тому моменту идей. Релиз GNU Emacs 13 (первой публичной версии) состоялся 20 марта 1985 года.

GNU Emacs принципиально отличался от своих предшественников двумя вещами.

Во-первых, он был написан на собственном диалекте Lisp — Emacs Lisp (elisp). Сам Emacs состоял из небольшого ядра на C, в котором был интерпретатор elisp, и огромного объёма функциональности, написанной непосредственно на elisp. Это означало, что любую часть редактора можно изменить, не пересобирая его. Вы открываете .emacs-файл, пишете там пару строк на elisp, перезагружаете конфигурацию — и редактор уже работает по-новому. Любую функцию можно переопределить. Любую клавишу можно перенастроить. Любое меню можно перестроить. Это была не настройка редактора — это было программирование редактора прямо во время работы.

Во-вторых, он был свободным. GNU Emacs распространялся под GNU General Public License (GPL) — той самой лицензией, которую Столлман к тому моменту разрабатывал и которая впервые официально вышла в 1989-м. Любой человек мог взять Emacs, изучить его код, изменить под свои нужды, распространять дальше. И при этом любые производные работы тоже должны были оставаться свободными.

Эти два качества вместе превратили GNU Emacs в нечто большее, чем просто редактор. По выражению Столлмена, это был «self-documenting, customizable, real-time display editor» — «самодокументирующийся, настраиваемый редактор отображения в реальном времени». Под «самодокументирующимся» Столлман имел в виду, что любая команда Emacs знает, как объяснить, что она делает, прямо из самого редактора (нажмите C-h k и любую клавишу, и Emacs скажет, что эта клавиша делает, и покажет вам исходный код её обработчика).

5. Emacs как операционная система

К 1990-м годам Emacs накопил такой объём функциональности, что от него начали отшучиваться:

Emacs — это прекрасная операционная система, в которой не хватает только хорошего текстового редактора.

Шутка появилась не на пустом месте. Внутри Emacs к этому моменту жили:

GNU Info — браузер документации GNU, по сути локальный гипертекстовый редактор.
Gnus — почтовый и Usenet-клиент.
VM — другой почтовый клиент.
Org-mode — система ведения заметок и планирования, разработанная Карстеном Домиником в 2003-м; сегодня по ней пишут диссертации, ведут календари, делают презентации, управляют проектами.
Magit — клиент для Git, по общему мнению лучший в мире (даже многие пользователи терминала используют именно его).
TRAMP — прозрачный доступ к удалённым файлам по ssh, ftp, rsync и десяткам других протоколов прямо из редактора.
dired — файловый менеджер, по совместительству тоже редактор (можно прямо в нём массово переименовывать файлы, как обычный текст).
eshell — встроенная командная оболочка, написанная на elisp.
calc — научный калькулятор класса Mathematica, тоже целиком на elisp.
doctor — простейший ИИ-психотерапевт (реализация знаменитого ELIZA Джозефа Вейценбаума 1966 года).
tetris, snake, doctor — да, в Emacs встроены игры. Команда M-x tetris запускает Тетрис.

И всё это взаимодействует друг с другом через единый интерфейс. В одном буфере Emacs у вас может быть открыт код на Python, рядом — Org-mode-документ с TODO-листом, в нижней панели — терминал с запущенным тестом, в правой панели — Magit с пуш-кнопкой, и всё это управляется одними и теми же базовыми клавиатурными сочетаниями. По сути, это окружение, которое заменяет вам половину операционной системы. Многие пользователи Emacs действительно проводят в нём весь рабочий день, выходя только за браузером и видеоконференциями.

Шутка про «операционную систему» не такая уж и шутка.

6. И в это же время в Беркли — vi

Параллельно, в том самом 1976 году, в Калифорнийском университете в Беркли разворачивалась совсем другая история.

Билл Джой — аспирант, который через несколько лет станет одним из основателей Sun Microsystems и автором языка Java-подобной модели concurrent computing, — сидит дома в Беркли. У него медленный модем (300 бод) и терминал ADM-3A без отдельных клавиш стрелок. Он работает с редактором ed — текстовым линейным редактором Кена Томпсона, в котором вы пишете команды одну за другой, и редактор показывает по одной строке за раз. Это утомительно.

Летом из Лондона приезжает в гости Джордж Куло́рис, преподаватель Queen Mary College, который незадолго до этого написал свой собственный редактор em (editor for mortals — «редактор для смертных») — улучшенную версию ed с полноэкранным интерфейсом. Куло́рис показывает свой em Джою. Джой впечатляется.

В течение следующих месяцев Джой и Чак Хейли пишут поверх ed свой собственный редактор — сначала en, потом ex, в октябре 1977-го добавляют к ex полноэкранный визуальный режим. Этот визуальный режим вызывается командой vi — сокращением от visual.

К марту 1978 года ex 1.1 выходит в составе первой Berkeley Software Distribution (BSD) UNIX. К маю 1979 во второй BSD редактор поставляется уже под отдельным именем vi, которое сразу запускает ex в визуальном режиме. С этого момента vi — стандартный редактор UNIX на следующие сорок лет.

В 1991 году голландец Брам Моленар напишет Vim (Vi Improved) — улучшенный клон vi, который сегодня и считается «тем самым vi» практически в любом контексте.

7. Почему vi такой странный

vi знаменит модальной моделью редактирования. Когда вы открываете vi, вы оказываетесь в командном режиме (Normal mode), в котором обычные буквы алфавита не печатают букву, а выполняют команды. j — спустить курсор на строку вниз. k — поднять на строку вверх. h — налево. l — направо. d плюс что-то — удалить. y — скопировать. p — вставить. Чтобы начать вводить текст, надо специально нажать i (insert) или a (append) — переключиться в режим ввода. Потом, чтобы вернуться в командный режим, нажимаете Escape.

Это контринтуитивно. Это сразу отпугивает новичков (есть бесчисленные мемы про людей, открывших vi и не сумевших выйти). И при этом это гениально эффективно, если потратить пару недель на привыкание: в vi сложные правки выполняются за два-три нажатия клавиш. Удалить три слова — d3w. Скопировать абзац — yap. Заменить всё «foo» на «bar» в файле — :%s/foo/bar/g. Эти команды складываются в грамматику, в которой оператор (что делать) сочетается с движением (с чем именно), и в этой грамматике можно выразить почти любую правку.

Почему Джой сделал именно так? Он сам объяснял много раз — это были вынужденные ограничения. У него был медленный модем — 300 бод, то есть около 30 байт в секунду. Это значит, что обновить весь экран было операцией мучительно медленной: пара секунд. У Джоя не было возможности позволить редактору перерисовывать экран после каждого нажатия. Поэтому он сделал команды короткими, однобуквенными и немодальными в смысле обновления экрана: одно нажатие — одно изменение в файле, без перерисовки. Это и было то самое модальное редактирование, которое позволяло работать осмысленно даже через 300 бод.

«Люди, делавшие Emacs, сидели в лабораториях MIT с тем, что по нынешним меркам было оптоволоконными каналами связи. Они работали на PDP-10, огромной по сравнению с нашим железом машине, с бесконечно быстрыми экранами. Поэтому у них могли быть забавные команды с мерцанием экрана и всё такое. А я в это время сидел дома в бараках излишков после Второй мировой войны на территории Беркли, с модемом и терминалом, который еле выводил курсор. Это был мир, который сейчас вымер. Люди не знают, что vi был написан для мира, которого больше нет».
— Билл Джой, интервью Linux Magazine, 1999

Эта цитата — лучший ключ к редакторским войнам. Vi был оптимизирован под жестокую экономию ресурсов. Emacs был оптимизирован под богатую интерактивную среду. Это не вопрос «кто прав», это вопрос «в каком мире вы живёте».

8. Модальный vs немодальный: философский раскол

Главное различие между Emacs и vi — даже не в конкретных клавишах, а в подходе к самой идее редактирования.

vi (и Vim) — модальный. Редактор всегда находится в одном из режимов: командном, ввода, визуального выделения, и т. д. Одна и та же клавиша делает разные вещи в разных режимах. Это даёт очень короткие, чистые, композициональные команды — но требует постоянно держать в голове, в каком режиме ты сейчас находишься.

Emacs — немодальный (modeless). Редактор всегда находится в одном и том же состоянии. Буквы алфавита печатают буквы. Команды вызываются через аккорды — нажатия Ctrl, Meta (Alt) и Super в комбинации с буквами. C-f (Ctrl-F) — на символ вперёд. M-f (Alt-F) — на слово вперёд. C-x C-s — сохранить. C-x C-c — выйти. Это похоже на то, как сегодня устроены сочетания в любом графическом приложении (Ctrl-C для копирования и т. д.) — только Emacs сделал это первым, ещё в 1976-м.

Из этой разницы вытекает всё остальное.

Кривая обучения. Vi/Vim страшнее в первые две недели, потом раскрывается. Emacs мягче в первые часы, но требует постоянного запоминания клавиатурных аккордов, которых сотни.

Расширяемость. vi настраивается через VimScript (или Lua в новейшем Neovim). Emacs настраивается через Emacs Lisp — полноценный диалект Lisp, в котором написан сам Emacs, и в котором можно прямо во время работы переопределить любую функцию редактора.

Объём функциональности. vi — заточен под одну задачу: эффективное редактирование текста. Emacs стремится охватить всё рабочее окружение программиста.

Запуск. vi запускается мгновенно. Emacs — традиционно медленно (хотя в Emacs 28 появилась нативная компиляция elisp, которая ускорила всё в разы, и время запуска сократилось с нескольких секунд до полусекунды).

Эмоциональная окраска у пользователей. Vi-пользователи обычно считают, что они выбрали инструмент минимализма и эффективности. Emacs-пользователи — что они выбрали инструмент глубины и универсальности. Каждая сторона свысока поглядывает на другую.

Религия в чистом виде.

9. Редакторские войны

Война началась в Usenet примерно в 1985 году и идёт до сих пор. На любой популярный пост про текстовые редакторы в HackerNews, Reddit или Lobste.rs предсказуемо приходят люди обеих сторон и начинают спор, в котором не убедить никого. На GitHub есть проекты, чья единственная цель — троллить противоположную сторону. Шутки про «как выйти из vi» стали мемами.

Эрик Реймонд в The Jargon File зафиксировал: «editor war» — устойчивый термин хакерского лексикона с 1985-го.

При этом сама война давно стала почти карикатурной. Эпоху, когда выбор редактора реально определял продуктивность программиста, давно сменила эпоха IDE с автодополнением, рефакторингом, LSP-серверами и графическими интерфейсами. Сегодня большинство профессиональных программистов пользуются VSCode, JetBrains-IDE или Cursor, и эти инструменты вобрали в себя всё лучшее из обоих миров: VSCode имеет официальный плагин Vim-эмуляции (модальное редактирование) и Emacs-keymap (немодальное), JetBrains-IDE — то же самое.

Но люди, которые остались на чистом Emacs или Vim, сделали это сознатель. Они уже знают, что VSCode существует, но он им не подходит. Им нужен инструмент, в котором они сами решают, как будут работать, а редактор указывает, как с ним взаимодействовать.

Это в каком-то смысле и есть главный водораздел: между готовым и настраиваемым. И Emacs здесь — крайняя точка спектра «настраиваемого».

10. Современный Emacs: Doom, Spacemacs и Lisp-возрождение

Если бы Emacs остался редактором из 1985 года, он бы давно умер. Но он умудрился пережить четыре больших технологических сдвига: переход с PDP-10 на UNIX, переход на персональные компьютеры, переход на графические среды, теперь — переход к LSP/Tree-sitter/нативной компиляции.

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

Emacs 28 (2022) — нативная компиляция elisp. До этого все функции редактора интерпретировались на ходу, что для миллионов строк elisp означало заметную медлительность. Native-comp компилирует elisp в нативный машинный код, и в результате Emacs стал в 3–10 раз быстрее по большинству операций.

Emacs 29 (2023) — встроенная поддержка LSP (Language Server Protocol, тот же протокол, на котором работают VSCode-плагины для языков) и Tree-sitter (новый стандартный парсер для подсветки синтаксиса). Это означает, что любой современный язык программирования из коробки работает в Emacs с тем же уровнем умных подсказок, что и в VSCode.

Pure GTK (Emacs 29) — нативная поддержка Wayland. Emacs наконец-то работает на современном Linux-десктопе без хаков.

И главное — два дистрибутива Emacs, которые радикально упростили вход в этот мир:

Spacemacs — появился в 2014 году, изначально как «Emacs для перебежчиков из Vim». Из коробки идёт с Evil-mode (полная Vim-эмуляция, можно использовать клавиши h/j/k/l, командный режим и т. д.) и красивым, продуманным интерфейсом. Все настройки делаются через декларативный конфигурационный файл с понятными «слоями» функциональности.
Doom Emacs — появился в 2017-м. Минималистичнее Spacemacs, ближе к обычному Emacs, очень быстро запускается (благодаря native-comp — меньше секунды от вызова команды до полностью готового окна). Стал в последние пару лет основным «дистрибутивом Emacs для новичков». Я бы сказал, что сегодня большинство людей, открывающих Emacs впервые, начинают с Doom.

Оба дистрибутива решают главную традиционную проблему Emacs, что без двух-трёх лет настройки он выглядит почти так же, как в 1985 году. С Doom или Spacemacs вы получаете готовое современное окружение прямо из коробки.

В сообществе сейчас (2026 год) — небольшой ренессанс. Люди возвращаются к Emacs после многих лет в VSCode по двум причинам. Первая: org-mode действительно лучшая в мире система ведения заметок и личных знаний, и попытки её клонировать вне Emacs (Logseq, Foam) до сих пор не дотягивают. Вторая: Magit действительно лучшая в мире обвязка над Git, и пользователи Magit обычно остаются в Emacs ровно ради него.

11. Lisp как тайная сверхспособность

Я уже упоминал, что Emacs написан в основном на Emacs Lisp (elisp) — собственном диалекте Lisp. Этот факт обычно подаётся в технических обзорах как любопытная деталь. На самом деле это сердце всей идеологии Emacs.

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

В Emacs конфигурация — это код. Ваш ~/.emacs.d/init.el — не настройки, а программа на Lisp, которую Emacs выполняет при запуске. Эта программа может определять новые функции, переопределять старые, добавлять хуки на события, переписывать поведение любых частей редактора. И, что важнее всего, эту программу можно изменять прямо во время работы: написали функцию, нажали C-x C-e — и она тут же доступна. Никаких перезапусков.

Это — то самое, что делает Emacs уникальным. Это не настраиваемый редактор. Это Lisp-машина, в которой по совместительству есть текстовый редактор. Большая часть функциональности Emacs реализована не в C, не в скомпилированном виде, а как обычные elisp-функции, которые вы можете прочитать, изменить, заменить.

Это требует определённого склада ума: вам должно быть интересно писать код, чтобы он редактировал текст. Если вам нужно просто эффективно набирать текст и не возиться с интеграциями, вам не нужен Emacs. Лучше используйте VSCode или Vim. Но если вы из тех, кому нравится сама идея «программируемого окружения», — вы найдёте в Emacs друга на всю жизнь.

Это, кстати, ещё одно объяснение, почему Emacs всё ещё жив через полвека. Внутри него — Lisp, один из самых выразительных и долгоживущих языков программирования в истории (Lisp придумал Джон Маккарти в 1958-м, и он переживает уже несколько эпох; я уже запланировал написать про Lisp отдельный пост). А Lisp устроен так, что может моделировать любые другие парадигмы программирования — то, что мы сегодня называем функциональным программированием, было в Lisp с самого начала. Объектное программирование? CLOS. Метапрограммирование? Макросы. Асинхронность? Что угодно. Поэтому elisp-сообщество всегда могло добавить в Emacs любую современную парадигму: Lisp как язык настолько гибок, что встраивает их без боли.

В vi такой возможности нет. Vim-script — это специализированный язык исключительно для настройки Vim, в нём невозможно написать ничего интересного за пределами редактора. Когда сообщество Vim это поняло, они сделали Neovim — современный форк, который вместо VimScript использует Lua. Это шаг в правильном направлении, но это всё равно не Lisp-машина: Lua вшивается в Neovim как чужеродный язык, а elisp и есть Emacs.

12. Что в итоге выбрать в 2026 году

Если вы ещё не выбрали инструмент и думаете, стоит ли в 2026 году учить Emacs или Vim, мой честный ответ — зависит от того, чего вы хотите.

Если вам нужен просто хороший редактор, который работает из коробки и в котором можно писать код — берите VSCode, Sublime Text, Zed или JetBrains-IDE. Через десять минут после установки вы продуктивны.

Если вы цените эффективное модальное редактирование и хотите минималистичный инструмент — берите Vim (или Neovim). Через две недели практики вы научитесь работать в нём быстрее, чем в любом IDE.

Если вы любите идею программируемого окружения, обожаете возиться с инструментом, хотите org-mode и Magit, и готовы вложить полгода в постепенное обживание системы — берите Emacs. Лучше всего Doom Emacs: это самый быстрый способ войти в современный Emacs без болезненных трёх лет настройки.

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

Сам факт, что в 2026 году инструмент, разработанный в 1976-м, до сих пор остаётся для значительной доли программистов рабочим выбором — он не случайный. Emacs пережил столько технологических эпох, потому что внутри него — не редактор, а программируемое окружение. А окружение, в котором можно перепрограммировать что угодно, не устаревает: оно подстраивается под любую новую эпоху своими же средствами.

13. Финал: два мира, одна задача

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

И в этом — главное наблюдение про инструменты программиста. Хороший инструмент — это не «правильный», а тот, который вы выбираете в полном осознании альтернатив. Vim — отличный выбор, если вы цените модальное редактирование и минимализм. Emacs — отличный выбор, если вы хотите программировать сам редактор. VSCode — отличный выбор, если вам нужно работать прямо сейчас, без месяцев настройки. Vim и Emacs в 2026-м — это не «лучше, чем VSCode». Это другое решение задачи, которое подходит другому типу человека.

Сам я работаю в Neovim, и он мне нравится: модальное редактирование, Lua-конфигурация, быстрая интеграция с LSP — всё на месте. Но к Emacs у меня глубокое уважение, несмотря на то, что я пока им не пользуюсь. Мне нравится сама идея, что редактор может быть в первую очередь Lisp-машиной, в которой можно написать что угодно. И что после полувека развития эта Lisp-машина всё ещё живёт, развивается и обрастает новой функциональностью — нативной компиляцией, LSP-сервером, Tree-sitter, Wayland, чем угодно. Без шума, без рекламы, без венчурного финансирования. Просто потому, что определённый тип людей продолжает её использовать и улучшать.

В следующем посте я расскажу про Lisp — язык, который оказался внутри Emacs и который сам по себе живёт уже почти семьдесят лет. У него ещё более удивительная история.

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

Историческое

The original announcement of EMACS, Стэнфорд, 1981 — статья Столлмена об устройстве и философии раннего Emacs. Читается отлично, многое из тогдашних соображений до сих пор актуально.
Emacs Historical Archive — собрание оригинальных исходников TECO-Emacs, MulticsEmacs, Gosling Emacs и других.
«Where Vim Came From» — отличная популярная статья о происхождении vi из ed → em → ex → vi.
«The True History of vi» (Lunduke) — детальная хронология истории vi.

Современный Emacs

Doom Emacs — рекомендованный мной дистрибутив для входа в современный Emacs.
Spacemacs — альтернативный дистрибутив, более «фреймворковый».
Mastering Emacs — лучший современный сайт-учебник по Emacs.
Emacs Wiki — гигантская коллективная wiki со всем, что нужно знать.

Видео

📺 «Emacs is sexy» — обзор современных возможностей Emacs (2023).

📺 Getting Started With Doom Emacs — серия видео про Doom Emacs.

Для сравнения — Vim

Vim Tutor — стандартный туториал, поставляется с любым Vim/Neovim, запускается командой vimtutor.
Neovim — современный форк Vim с поддержкой Lua и LSP.
«The Editor War» — статья в Википедии об истории редакторских войн.

Ричард Столлман: пророк свободного софта

2026-05-28T15:58:37.926Z

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

Уже после этого обсуждения я задумался и восхитился, насколько один человек может быть последователен в своих убеждениях. Не просто декларировать что-то правильное на сцене, а реально, день за днём, сорок с лишним лет жить по этим декларациям без поблажек самому себе. Не пользоваться смартфоном. Не открывать ни одну веб-страницу, на которой исполняется несвободный JavaScript. Не подключаться к Wi-Fi, который требует регистрации. Не пользоваться сервисами Google, Amazon, Apple, Microsoft. Не летать самолётами компаний, требующих биометрию. Не давать интервью изданиям, не публикующим материалы под свободной лицензией. И при этом — продолжать программировать в Emacs на ноутбуке с открытой BIOS-прошивкой, выступать с лекциями по всему миру, и за эти годы построить юридический и этический фундамент, на котором сегодня держится вся индустрия открытого программного обеспечения.

Этот человек — Ричард Мэтью Столлман, основатель Фонда свободного программного обеспечения (Free Software Foundation, FSF), автор GNU Manifesto, главный архитектор операционной системы GNU, создатель GNU General Public License (GPL) — самой популярной свободной лицензии в мире, изобретатель понятия «копилефт» и идеолог всего движения свободного программного обеспечения.

В этом посте я хочу рассказать об этом по-настоящему неординарном человеке. О его жизни от ребёнка-вундеркинда из Манхэттена до седого пророка с бородой. О том, как в 1980 году сломавшийся лазерный принтер Xerox привёл его к идее, которая через сорок лет станет фундаментом каждого открытого проекта на GitHub. О четырёх свободах и о его образе жизни, который большинство сочтёт чудачеством. О его блистательной репутации учёного и о спорах вокруг его личности, в том числе о скандале 2019 года и возвращении в совет директоров FSF в 2021-м. И о том, почему фотография с его автографом на стене у моего коллеги — это не сувенир, а артефакт почти религиозного значения для многих людей в нашей индустрии.

1. Манхэттен, 1953: дитя, рождённое для машин

Ричард Мэтью Столлман родился 16 марта 1953 года в Нью-Йорке. По его собственной шутке, «собран в одной из лабораторий Манхэттена около 1953 года». В этой шутке больше правды, чем кажется: с раннего детства Ричард производил впечатление мальчика, чей ум устроен иначе, чем у сверстников.

Мать — Алиса Липпман, школьная учительница и активистка. Отец — Дэниел Столлман, ветеран Второй мировой войны, печатник. Родители развелись, когда Ричарду было около десяти. Воспитывала его мать, в Манхэттене.

Калькуляторы и цифровые штуки Ричард полюбил рано. Уже в семь-восемь лет он самостоятельно изучил школьный курс математики на годы вперёд. К двенадцати уже учился в летней лагерной программе для одарённых школьников, к четырнадцати попал в IBM на программу для подростков и впервые написал собственную программу, симулятор работы процессора IBM 7094 на языке APL. Это было лето 1969 года. Через десять лет на этой же платформе будут писать программисты NASA.

В 1970-м Ричард поступил в Гарвардский университет на математический факультет. Учился отлично, но всё свободное время проводил в MIT — в соседнем кампусе, где была легендарная Лаборатория искусственного интеллекта (MIT AI Lab). Уже на первом курсе Гарварда — в 1971-м — он стал постоянным сотрудником этой лаборатории и нашёл там свой настоящий дом.

2. MIT AI Lab: культура хакеров и совместного знания

Чтобы понять Столлмена, надо понять MIT AI Lab начала 1970-х.

Это было одно из мест, где родилась культура хакеров в исходном смысле этого слова, где хакером называли не взломщика/преступника, а человека, который виртуозно владеет своей программой и любит её улучшать. Лаборатория жила по правилам, которые сейчас кажутся невозможными: круглосуточный открытый доступ, никаких паролей на машинах (Столлман считал пароли «не-академической практикой»), общий код, открытые шкафы с ключами от всех помещений, неформальный обмен наработками. У лаборатории даже была так называемая «туристическая политика»: любой человек с улицы мог зайти, сесть за свободный терминал и поработать, если он не мешал штатным исследователям.

Программисты-хакеры в этой среде образовывали маленькое племя со своим арго, своими шутками и ритуалами. Они работали на компьютерах, изготовленных в самом MIT — в первую очередь на машинах PDP-10 под управлением операционной системы ITS (Incompatible Timesharing System), которая, как и почти всё ПО в лаборатории, была написана самими хакерами и распространялась без всяких ограничений.

В этой среде прошли годы становления Столлмена. Он быстро стал одним из ведущих программистов лаборатории, известным во всей хакерской сети ARPANET под коротким логином RMS — Richard Matthew Stallman. К концу 1970-х он считался одним из самых способных программистов планеты. Среди его разработок того времени — текстовый редактор Emacs, который он начал писать в 1976-м и который сейчас, спустя ровно полвека, всё ещё активно разрабатывается и используется миллионами программистов.

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

Но именно тогда эта культура начала разрушаться.

3. 1980 год, лазерный принтер Xerox и моральная катастрофа

В 1980 году MIT получила в подарок от компании Xerox новейший лазерный принтер Xerox 9700. Это была вершина тогдашней техники: дорогой, быстрый, способный печатать на профессиональном уровне.

Принтер быстро стал популярным в лаборатории. Но он стоял на отдельном этаже от большинства пользователей, и у него была одна неприятная особенность: он периодически зажёвывал бумагу. Старый принтер — XGP, тоже от Xerox, — у Столлмена был доработан собственноручно: программа отслеживала статус задания и уведомляла пользователя, когда печать готова или когда случилась поломка. Все были довольны, не надо было зря бегать на другой этаж.

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

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

Преподаватель отказал. Сказал, что подписал с Xerox соглашение о неразглашении (NDA), и поделиться кодом не имеет права.

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

Сэм Уильямс в биографии «Free as in Freedom» (доступной целиком онлайн под свободной лицензией) пишет, что Столлман вышел из кабинета этого профессора в состоянии, которое сам потом сравнит с религиозным шоком. Он осознал, что мир хакеров, в котором он вырос, заканчивается. Что программисты теперь могут жить в режиме обязательного молчания друг перед другом. Что любой код, в который он или его коллеги когда-либо внесут вклад, может оказаться запертым за корпоративными NDA. Что это не отдельный плохой инцидент, а символ наступления новой эпохи.

К 1981–1982 годам ситуация в самом MIT AI Lab подтвердила его страхи. Лаборатория раскололась: компания Symbolics, основанная бывшими сотрудниками, переманила к себе почти всех ведущих хакеров и стала разрабатывать проприетарные версии того кода, который раньше был общим. Лаборатория опустела. Столлман в одиночку с 1982-го по конец 1983-го пытался воспроизводить наработки Symbolics для оставшейся в MIT системы, чтобы у компании не сложилась монополия. Это было физически и эмоционально изматывающее занятие, и оно показало ему, что бороться за прошлое бесполезно. Нужно строить будущее.

4. 27 сентября 1983: анонс GNU

27 сентября 1983 года Столлман отправил в несколько списков рассылки ARPANET и Usenet (новостные группы net.unix-wizards и net.usoft) короткое объявление под заголовком «new UNIX implementation» — «новая реализация UNIX». В нём говорилось примерно следующее:

«Начиная с этого Дня Благодарения, я планирую написать полностью совместимую с UNIX систему программного обеспечения под названием GNU (Gnu’s Not Unix), и раздавать её бесплатно всем, кто может ею воспользоваться. Очень нужны помощники, время, деньги, программы и оборудование».

Название GNU — рекурсивный акроним: G — Gnu, N — Not, U — Unix. То есть «GNU’s Not Unix». Типично хакерская шутка: имя проекта содержит ссылку на самого себя, и распаковать её можно бесконечно (GNU’s Not Unix’s Not Unix’s Not Unix…). Произносится с твёрдым «г»: «гну».

Революционность этого анонса была в том, что прежде ни у кого в индустрии не было идеи с нуля, построить полностью свободную операционную систему, в которой каждый компонент мог бы быть открыт, изменён и распространён без ограничений. UNIX, который был на тот момент эталоном, был частной собственностью AT&T. Microsoft DOS — Microsoft. VMS — DEC. Все мощные ОС были чужой собственностью.

Столлман предложил построить собственную ОС, совместимую с UNIX, но свободную: исходный код открыт, любому можно изучать, изменять и распространять. И реализовать полный стек: GNU Emacs, GNU C Compiler, GNU debugger, GNU shell, всё необходимое для нормальной работы программиста. И сам взялся за разработку — в одиночку, без ресурсов и без чьего-либо заказа.

К январю 1984 года Столлман уволился из MIT, чтобы у лаборатории не было прав на его новые программы и она не могла лицензировать их корпорациям. Он остался работать в лаборатории как «приглашённый учёный» (visiting scientist) без зарплаты — этот статус у него сохранялся до 2019 года. До конца 1990-х он в буквальном смысле жил и спал в своём офисе в MIT, чтобы сэкономить на жилье и тратить все ресурсы на GNU.

5. 1985: GNU Manifesto и Фонд свободного ПО

В марте 1985 года Столлман опубликовал в журнале Dr. Dobb’s Journal документ под названием «GNU Manifesto» — манифест GNU. На сегодня этот текст переведён на десятки языков, в том числе на русский, и читается всё так же ясно.

Манифест — это, по сути, программное заявление: что такое GNU, зачем он нужен, какую этическую позицию он отстаивает, почему программисты не должны соглашаться на проприетарную модель. В нём же впервые ясно сформулирована идея, что «свободное» в выражении „свободное программное обеспечение" — это не „бесплатное", а „без ограничений". «Think free as in free speech, not as in free beer» — «думайте свободно, как в выражении „свобода слова", а не как в „бесплатное пиво"».

В октябре 1985 года Столлман основал Free Software Foundation (FSF) — некоммерческую организацию, целью которой стало поддерживать разработку свободного ПО, нанимать программистов на работу над GNU, защищать свободные лицензии в суде и пропагандировать ценности свободного ПО. FSF существует до сих пор, базируется в Бостоне, имеет филиалы в Европе, Латинской Америке и Индии.

С этого момента «свободное ПО» перестало быть туманной идеей и стало конкретным движением со своим уставом, своей юридической базой и своим лидером.

6. Четыре свободы

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

Свобода 0 — свобода запускать программу для любых целей.
Свобода 1 — свобода изучать, как программа работает, и изменять её под свои нужды.
Свобода 2 — свобода распространять копии программы, чтобы помогать другим.
Свобода 3 — свобода распространять копии своих изменённых версий программы.

Заметили нумерацию? Она с нуля. Столлман — программист, и для него начало отсчёта — это 0, а не 1. Историческая причина: изначально свобод было три, с номерами 1, 2, 3. Позже Столлман понял, что «право запускать программу» само по себе тоже надо явно перечислить, и добавил его — но не перенумеровывать же уже устоявшиеся 1, 2, 3, поэтому добавилась «свобода 0». Шутка, ставшая канонической.

Все эти свободы перечислены на странице gnu.org и являются официальным определением свободного ПО, на которое опираются все свободные лицензии — GPL, LGPL, AGPL и десятки других. Если программа нарушает хотя бы одну из этих свобод, она по определению не свободна, а проприетарна.

7. Копилефт и GPL: гениальный юридический хак

Между 1985 и 1989 годами Столлман сделал то, что я считаю одним из самых элегантных юридических ходов в истории технологий.

Проблема была такая: если просто положить программу в общий доступ (public domain), то любой может взять её, добавить туда свои изменения и закрыть результат проприетарной лицензией. То есть свобода исходного кода теряется на первом же шаге.

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

Этот трюк Столлман назвал «копилефт» (copyleft) — анти-копирайт, но на основе того же юридического механизма. Каламбур: правая часть слова «copyright» (left ↔ right), но также и игра на «I left a copy».

В 1989 году Столлман выпустил первую общую версию своей лицензии — GNU General Public License version 1 (GPLv1). Это была первая программно-независимая лицензия, основанная на принципе копилефта. В 1991-м вышла GPLv2, в 2007-м — GPLv3 (значительно усиленная против корпоративных приёмов обхода свободы через DRM и патенты). Сегодня GPL — самая популярная свободная лицензия в мире. Под ней выпущены ядро Linux, GCC, Git, Bash, MySQL/MariaDB и тысячи других проектов. По разным оценкам, под лицензиями семейства GPL выпущено около 30–35 % всего свободного ПО в мире.

И в основе всего этого — очень умный юридический трюк одного очень упрямого человека.

8. GNU + Linux = «GNU/Linux»

К началу 1990-х у GNU было почти всё: компилятор GCC, отладчик GDB, текстовый редактор Emacs, оболочка Bash, утилиты coreutils, целый набор системных программ. Не было одного: ядра операционной системы. Над собственным ядром под названием GNU Hurd Столлман и его команда работали с 1990 года, но Hurd оказался технически сложным и затянулся на годы (он, кстати, всё ещё разрабатывается, но в основном как академический эксперимент).

В 1991 году финский студент Линус Торвальдс объявил о начале работы над собственным ядром под именем Linux и быстро довёл его до рабочего состояния. Все утилиты GNU отлично с ним работали. Получалась полноценная операционная система. И именно эту комбинацию весь мир сегодня знает как «Linux».

Столлман по этому поводу до сих пор спорит, и спорит обоснованно. По его настоянию правильное название комбинированной системы — GNU/Linux (произносится «GNU слэш Linux» или «GNU плюс Linux»), потому что Linux — это только ядро, а вся операционная система состоит из ядра Linux плюс пользовательского пространства GNU. Это не педантизм, а вопрос исторической справедливости: GNU был спроектирован за восемь лет до Linux, и большая часть инструментов, которые делают «Linux» полезной для пользователя, написана командой GNU.

В русскоязычном пространстве эта борьба за название почти проиграна — все говорят «Linux». Столлман в каждом своём выступлении просит коллег говорить GNU/Linux. Это, пожалуй, единственная битва, в которой он проигрывает год за годом.

9. Образ жизни: убеждения, доведённые до конца

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

Вот, например, что Столлман делает и не делает (он сам подробно описал свой быт на своей странице):

Не пользуется смартфоном. «Мобильный телефон — это мечта Сталина. Я не собираюсь носить с собой устройство, которое регистрирует каждое моё движение и которое в любой момент могут включить на прослушку».
Использует только ноутбуки со свободной BIOS-прошивкой. Долгое время это был Lemote Yeeloong — китайский нетбук на процессоре Loongson, единственный на тот момент, способный загрузиться с полностью свободным BIOS. Позже — ThinkPad X60, T400s, сейчас — ThinkPad X200 с Libreboot (свободная замена проприетарного UEFI) и дистрибутивом Trisquel (один из официально одобренных FSF полностью свободных дистрибутивов GNU/Linux).
Не пользуется браузером в обычном режиме. Просит коллег скачивать ему страницы по электронной почте отдельно, чтобы он мог их прочесть без выполнения JavaScript.
Не открывает страницы с нетривиальным несвободным JavaScript (а это сегодня около 99 % веба).
Не пользуется DRM-контентом. То есть — не смотрит Netflix, не слушает Spotify, не покупает Kindle-книги.
Не пользуется Google, Amazon, Facebook, Apple, Microsoft — ни одним из их сервисов.
Не подключается к Wi-Fi, требующему регистрации или JavaScript для авторизации.
Не летает самолётами компаний, требующих биометрическую идентификацию.
Большую часть времени работает в Emacs в текстовой консоли, потому что мышь — это лишнее.

Когда его ноутбук украли в 2012 году в Аргентине, Столлман купил похожий и продолжил работать.

Многие считают это чудачеством, даже нелепостью. Но если задуматься, каждое его «нет» — это последовательное применение его же собственного манифеста. Если вы серьёзно верите, что несвободное ПО — это этическая проблема, нельзя одновременно верить в это и пользоваться WhatsApp. Большинство людей решают этот когнитивный диссонанс одним из двух способов: либо перестают верить в принцип, либо начинают делать исключения «по жизненной необходимости». Столлман — третий путь: он строит свою жизнь так, чтобы исключения были не нужны. Это сложно, неудобно, изолирует от 95 % современной инфраструктуры, однако он живёт так уже сорок с лишним лет.

10. Святой ИГНУций и Песня свободного ПО

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

Этот механизм — Святой ИГНУций (Saint IGNUcius). С 1996 года Столлман периодически выходит на сцену в чёрной рясе, нацепляет на голову нимб (на самом деле — старый магнитный диск от винчестера) и объявляет, что он — святой Церкви Emacs, и любой желающий может тоже стать святым этой Церкви. У Церкви Emacs нет богов («пока», как он осторожно добавляет), но есть гимн — «Free Software Song», и Святой ИГНУций иногда соглашается его спеть. Слова он приводит на своём сайте, мелодия позаимствована из болгарской народной песни «Садим момчета».

📺 Видео:

Richard Stallman performs as Saint IGNUcius in the Church of Emacs — Столлман наряжается в рясу и нимб из пластины от HDD.

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

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

11. Признание и награды

За свою работу Столлман получил много премий:

1990 год — MacArthur Fellowship («премия гениев»). Это $500 000, выплачиваемых в течение пяти лет, без каких-либо условий. Столлман потратил большую часть этих денег на работу FSF.
1991 — Grace Hopper Award от ACM «за первую реализацию расширяемого редактора Emacs».
1996 — степень почётного доктора Королевского технологического института Швеции.
1998 — EFF Pioneer Award от Electronic Frontier Foundation.
2001 — Takeda Award за общественную и культурную работу (один миллион долларов, на разработку GNU).
2002 — членство в National Academy of Engineering США.
2004 — National Academy of Sciences (член).
2015 — ACM Software System Award (за GCC, вместе с авторами).

А ещё у него есть с десяток почётных докторских степеней от университетов по всему миру — Глазго, Лионе, Латиноамериканской свободной школы, в Барселоне, Лейдене.

12. 2019 год: скандал, отставка и его последствия

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

В августе 2019 года в США появились новые материалы о деле финансиста Джеффри Эпштейна, известного своими сексуальными преступлениями против несовершеннолетних. Выяснилось, что Эпштейн жертвовал значительные суммы Медиа-лабу MIT. Директор Медиа-лаба Джой Ито был вынужден уйти. Внутри MIT начался разбор связей института с Эпштейном, в том числе обсуждалось, кто из преподавателей с ним общался. В обсуждении всплыл покойный к тому моменту легенда ИИ-исследований Марвин Мински, в адрес которого одна из жертв Эпштейна, Вирджиния Джуффре, заявила, что её, тогда несовершеннолетнюю, отправляли заниматься сексом с Мински.

В этой почтовой рассылке Столлман публично возразил против формулировки «Мински напал на несовершеннолетнюю». Он не оправдывал Эпштейна — называл его «серийным насильником». Но насчёт Мински написал, что тот, скорее всего, не знал, что Джуффре несовершеннолетняя и что её принуждали к сексу, потому что Эпштейн имел все мотивы скрывать это от своих гостей. Дальше Столлман развил тезис, который для многих стал последней каплей: что определение «изнасилования» в современном американском праве «морально абсурдно», когда оно зависит от «незначительных деталей вроде того, в какой стране это произошло или сколько лет было жертве — 17 или 18».

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

16 сентября 2019 года Столлман объявил об отставке с поста президента Free Software Foundation и со своей позиции «приглашённого учёного» в MIT, на которой он провёл к тому моменту 35 лет. В своём заявлении он написал, что уходит «из-за давления на меня и на MIT в связи с серией непониманий и неверных интерпретаций».

В октябре 2019-го 33 ведущих мейнтейнера проекта GNU выпустили совместное заявление, что поведение Столлмена «подорвало одну из ключевых ценностей проекта GNU — равенство всех пользователей», и потребовали коллективного решения о структуре проекта. Тем не менее, формально Столлман остался главой проекта GNU.

В марте 2021 года на конференции FSF LibrePlanet Столлман неожиданно объявил о своём возвращении в совет директоров FSF. Это вызвало вторую волну скандала: было опубликовано открытое письмо с требованием его повторного исключения, которое подписали более 4 000 человек, включая представителей крупнейших технологических компаний. Одновременно появилось ответное открытое письмо в защиту Столлмена, подписанное более чем 6 000 человек, в основном инженерами, которые считали критику в его адрес неверной интерпретацией контекста.

На сегодняшний день Столлман остаётся в совете директоров FSF и продолжает выступать с лекциями по всему миру. Раскол в сообществе свободного ПО, который начался с тех писем 2019-го, до конца не закрылся.

Этот эпизод — реальная и важная часть его биографии, и обойти его молчанием значило бы дать читателю односторонний портрет. Но и судить исключительно по нему о Столлмене тоже несправедливо: написанные им инструменты и придуманные им лицензии до сих пор работают каждый день — в каждом сервере на Linux, в каждом мобильном телефоне на Android (через ядро Linux), в каждом крупном открытом проекте под GPL. Это два разных уровня его наследия, и читателю важно знать оба.

13. Что Столлман на самом деле построил

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

GPL и её разновидности (LGPL, AGPL, GFDL) сегодня — это самое популярное семейство свободных лицензий в мире. На них работают ядро Linux, GCC, Git, Bash, MySQL/MariaDB, Inkscape, GIMP, Blender, OpenSSL (под другими совместимыми лицензиями), значительная часть PostgreSQL и тысячи других проектов. Концепция копилефта, которую Столлман придумал в 1985-м, стала тем юридическим механизмом, через который открытый код смог защищать сам себя от поглощения корпорациями.

GNU-инструменты — GCC, GDB, Emacs, Coreutils, Make — это базовый набор каждого юникс-подобного сервера в мире. Каждая сборка Android, каждый дистрибутив Linux, каждый Mac OS X (через утилиты GNU) опирается на код, написанный людьми из проекта GNU. На макбуке любого Apple-программиста стоит GCC, Bash и GNU Make. И ни Apple, ни Google ни доллара не платят FSF за это — таково условие GPL: либо ты вкладываешь свой код обратно в свободу, либо ты не пользуешься плодами свободного движения.

Free Software Foundation существует уже 40 лет. Это организация, которая до сих пор поддерживает проекты GNU, ведёт юридическую защиту разработчиков, организует ежегодную конференцию LibrePlanet и продолжает быть единственным крупным голосом, говорящим именно о свободе программ, а не об их «открытости» (между «free software» и «open source» Столлман видит принципиальное этическое различие, и регулярно об этом напоминает).

Концептуальный сдвиг: в массовое сознание программистов вошла мысль, что программное обеспечение может быть общественным благом, а не только товаром. Что лицензия — это инструмент защиты, а не нападения. Что свободный код — это базис, а не каприз. Эта мысль, которой Столлман отдал жизнь, изменила реальность всей отрасли: сегодня каждая крупная компания мира выпускает значительную часть своего кода под свободными лицензиями. Google, Microsoft, Meta, Apple, Amazon — все они в той или иной степени являются частью экосистемы, фундамент которой заложил Ричард Столлман в одиночку в 1983 году.

14. Что почитать и посмотреть

Самое главное:

The GNU Manifesto (1985) — оригинал, переведён на русский. 20 минут чтения. Тот документ, с которого всё началось.
Why Free Software Is Better Than Open Source — программное эссе о разнице между свободным ПО и открытым кодом.
Free Software, Free Society: Selected Essays of Richard M. Stallman — сборник его собственных эссе, изданный FSF, доступен бесплатно в PDF. Лучший компактный способ погрузиться в его философию.
Free as in Freedom (2.0) Sam Williams (с дополнениями самого Столлмена) — каноническая биография на английском. Доступна целиком онлайн под GFDL.

Видео:

📺 «What is Free Software?» — лекция Столлмена

Free software, Software Libero, Richard Stallman, Ginevra, TEDxGeneva 2014 — короткое выступление в формате TEDx в 2014 году.

📺 Free Software Song в исполнении автора

📺 «The danger of software patents» — отдельная сильная лекция о патентной системе

15. Финал

Возвращаясь к началу: фотография с автографом Столлмена на стене у моего коллеги — это не сувенир. Это символ.

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

Столлман не идеален. У него скверный характер, неудобные взгляды и есть страницы биографии, которыми вряд ли стоит гордиться. Но он сделал нечто настолько последовательно и настолько хорошо, что без его работы сегодня не было бы Android (через Linux), Ubuntu, Docker (через Linux), Kubernetes (через Linux), большей части веб-серверов мира, и в принципе той экосистемы открытого ПО, в которой мы все живём.

И при этом в свои семьдесят с лишним он каждый день встаёт, запускает Emacs в текстовой консоли на ThinkPad X200 с Libreboot и продолжает писать. Без смартфона. Без Google. Без поблажек самому себе. С тем же упрямством, с которым он сорок с лишним лет назад вышел из кабинета профессора в Карнеги-Меллоне и понял, что мир хакеров умирает.

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

Источники и дополнительное чтение

Stallman R. The GNU Manifesto, 1985. Русский перевод: gnu.org/gnu/manifesto.ru.html.
Stallman R. Free Software, Free Society: Selected Essays. FSF Press, расширенное издание 2010 года.
Williams S. Free as in Freedom (2.0): Richard Stallman and the Free Software Revolution. FSF Press, 2010. Каноническая биография под GFDL.
GNU General Public License — официальный текст и история всех версий.
Определение свободного программного обеспечения — четыре свободы.
Stallman R. How I Do My Computing. Подробный личный рассказ Столлмена о своём ежедневном быту.
Stallman R. RMS Lifestyle. Объяснение его жизненной позиции — отказа от смартфона, веба и т. п.
Saint IGNUcius — официальная страница Церкви Emacs.
Free Software Foundation: история организации. Хронология ключевых событий с 1985 по сегодня.
Statement on Stallman’s resignation, FSF, 16 September 2019. Официальное объявление 2019 года.
GNU maintainers’ joint statement, October 2019. Заявление 33 мейнтейнеров проекта.
Statement of FSF board on Stallman’s return, March 2021. Возвращение в совет директоров.
Open letter calling for Stallman’s removal, 2021.
Open letter in support of Stallman, 2021.

Клод Шеннон: жонглёр на моноцикле

2026-05-27T20:59:56.839Z

«Я всё это делаю не потому, что надеюсь, что из этого выйдет какая-то польза. Мне просто интересно».

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

При этом, если вы спросите случайного прохожего, кто такой Эйнштейн, он скорее всего ответит. Если спросите, кто такой Тьюринг, большинство тоже вспомнит. А если спросите, кто такой Клод Шеннон, люди пожмут плечами и переспросят: «Это ещё кто такой?»

Это особый вид несправедливости. Шеннон стоит вровень с самыми крупными умами XX века, но публика про него почти не слышала. Биограф Джимми Сони, выпустивший в 2017 году книгу A Mind at Play, назвал его «самым важным гением, о котором вы никогда не слышали, с интеллектом уровня Эйнштейна и Ньютона».

В этом посте я расскажу о мальчике из крошечного городка в Мичигане, у которого в четырнадцать лет уже была собственная телеграфная линия из колючей проволоки. О магистранте, в 21 год, написавшем работу, без которой не было бы ни одного процессора в мире. О военных годах в Bell Labs, где он шифровал разговоры Рузвельта и Черчилля и обедал с Аланом Тьюрингом. О том, как в 1948 году он в одиночку вывел теорию информации и подарил миру слово «бит». О мышонке Тесее, моноцикле, жонглировании и носимом компьютере для рулетки в Лас-Вегасе. О жене Бетти, которая паяла с ним реле и редактировала его статьи. И о том, как болезнь Альцгеймера тихо стёрла из памяти Шеннона ту цифровую революцию, которую он сам же и сделал возможной.

1. Гэйлорд, Мичиган

Клод Элвуд Шеннон родился 30 апреля 1916 года в Петоски, штат Мичиган, а вырос в соседнем городке Гэйлорд — городе с населением в три тысячи человек, в тех местах, где зимой замерзает озеро Отсего и куда летом приезжают рыбаки за окунем.

Его отец работал в местном суде и был, как тогда говорили, «деловым человеком». Мать преподавала иностранные языки в школе. Из родственников рядом жил двоюродный дядя Эдвин Шеннон, который держал в городке мастерскую и был любителем мастерить разные диковины. В дальних родственниках Шеннона по матери был Томас Эдисон, и в семье об этом не упускали случая упомянуть.

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

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

В 1932 году, в шестнадцать лет, Шеннон поступил в Мичиганский университет. Он защитил там сразу два бакалаврских диплома — по электротехнике и по математике — оба в 1936 году. Двойное образование, инженерное и математическое, окажется решающим для всего, что Шеннон сделает дальше.

2. Кембридж 1937: самая важная магистерская работа в истории

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

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

Он заметил, что цепи из реле, которые либо замкнуты (1), либо разомкнуты (0), на самом деле подчиняются законам, открытым в 1854 году английским математиком Джорджем Булем. Булева алгебра — это математика, оперирующая только двумя значениями, истиной и ложью, и операциями над ними: И, ИЛИ, НЕ. Долгое время Буль и его последователи считали это абстрактным разделом логики, далёким от практических применений. Но Шеннон увидел, что у этих абстрактных операций есть прямой физический аналог в виде последовательного и параллельного соединения переключателей.

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

В 1937 году, в возрасте двадцати одного года, Шеннон оформил эту мысль как магистерскую диссертацию: «A Symbolic Analysis of Relay and Switching Circuits» — «Символический анализ релейных и переключательных схем». Через год работа вышла в Transactions of the American Institute of Electrical Engineers и получила премию Альфреда Нобеля (не та Нобелевская, а отдельная инженерная награда, тоже именная). Психолог Говард Гарднер позже назвал эту магистерскую «вероятно, самой важной и самой замеченной магистерской работой за всё столетие».

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

3. Бункер на Манхэттене и встреча с Тьюрингом

Шеннон защитил докторскую в MIT в 1940 году. Тема — приложение алгебры к генетике (он не остановился на одной области, его интересовало всё). Сразу после защиты его взяли в Bell Telephone Laboratories в Нью-Йорке, тогдашнее частное королевство Bell System, где работали лучшие инженеры и физики Америки.

Шла Вторая мировая. Шеннона определили в группу, занимавшуюся управлением артиллерийским огнём с радаров и криптографической защитой телефонной связи. Главным его проектом стала система SIGSALY — аппаратура для зашифрованных телефонных разговоров между Уинстоном Черчиллем и Франклином Рузвельтом.

SIGSALY была чудовищной машиной — пятьдесят пять тонн оборудования, две комнаты, мощность 30 киловатт. Она использовала систему одноразовых блокнотов в виде записанных на грампластинки случайных шумов. А математическую основу её защиты разработал именно Шеннон. К концу войны эти размышления оформились в отдельную работу — «Communication Theory of Secrecy Systems» (опубликована в 1949-м, написана в 1945-м), — которая до сих пор считается первой формальной работой по математической криптографии. Многие современные книги по шифрам начинаются с цитаты из неё.

В январе 1943 года в нью-йоркскую лабораторию Bell приехал гость из Великобритании — Алан Тьюринг. Его официально командировали в Bell для обмена опытом по криптографии. Тьюринг и Шеннон обедали вместе несколько недель подряд. О чём они говорили, точно никто не знает: разговоры о шифровании держались в секрете. Но известно, что в это самое время Тьюринг рассказал Шеннону про свою довоенную работу по машинам, способным вычислить всё, что в принципе вычислимо. А Шеннон, в свою очередь, делился с Тьюрингом своей идеей о том, что любую информацию можно измерить количественно.

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

4. 1948: год, когда родилась информация

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

Для Bell Labs этот вопрос был совсем не теоретическим. Компания была фактическим монополистом телефонной связи в США. Любое улучшение в передаче сигнала — больше разговоров через тот же кабель, меньше шумов на междугородной линии, бо́льшая дальность по одному проводу — означало для неё дополнительную выручку. Но никакого формального определения «количества информации» в литературе не существовало. Люди говорили о «качестве сигнала», о «шуме», о «полосе пропускания», но между этими понятиями не было общего знаменателя.

В июле и октябре 1948 года в Bell System Technical Journal появилась статья в двух частях: «A Mathematical Theory of Communication» — «Математическая теория связи». 79 страниц. Один автор: Claude E. Shannon.

В этой статье Шеннон сделал то, чего не делал никто:

Во-первых, он определил информацию как математическую величину. Если у вас есть сообщение, которое может быть одним из N равновероятных вариантов, количество информации в нём — это log2(N) бит. То есть выбор между двумя равновероятными вариантами — это 1 бит информации. Между четырьмя — 2 бита. Между восемью — 3. Это не вопрос мнения, это математика.

Во-вторых, он ввёл в науку слово «бит». В самой статье Шеннон скромно отдаёт авторство своему коллеге по Bell Labs Джону Тьюки (John W. Tukey), который в служебной записке 1946 года предложил сократить «binary digit» до «bit». Но именно Шеннон сделал это слово единицей измерения. С 1948 года и до конца времён бит — это минимальная единица информации, и слово это никогда уже не вернётся к своему дотехническому смыслу («кусочек»).

В-третьих, он определил энтропию источника. Энтропия — это, по Шеннону, мера непредсказуемости. Если источник всегда выдаёт одну и ту же букву «А», его энтропия равна нулю — мы заранее знаем, что он скажет, информации в его сообщениях ноль. Если источник равновероятно выдаёт одну из 26 букв алфавита, его энтропия максимальна, log2(26) ≈ 4,7 бита на символ. Реальный английский язык, как показал Шеннон, имеет энтропию около 1,1 бита на букву: предсказуемости в нём много, потому что после «q» почти всегда идёт «u», а гласные следуют за согласными по предсказуемой схеме.

В-четвёртых — и это самое потрясающее, — он доказал теорему о кодировании для канала с шумом. У любого канала связи есть максимальная пропускная способность (по-английски Shannon limit, по-русски «предел Шеннона») — максимум бит в секунду, который через него можно передать без ошибок, при условии достаточно умного кодирования. До этой границы можно достичь сколь угодно низкого уровня ошибок. Перешагнуть её невозможно никаким алгоритмом, никаким количеством оборудования. Это закон природы, как скорость света.

И самое поразительное: Шеннон показал, что к этому пределу можно подойти сколь угодно близко, если применять достаточно сложное кодирование. Он не дал алгоритма (это сделают другие за последующие пятьдесят лет, и каждое продвижение к пределу Шеннона будет научным событием — алгоритмы Хэмминга, коды Рида–Соломона, турбокоды, LDPC). Но он доказал, что предел существует, и в принципе достижим.

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

Историк науки Джеймс Глик, написавший «Хаос» и биографию Фейнмана, поставил статью Шеннона на первое место среди событий 1948 года. На втором месте у Глика — публичная презентация транзистора, состоявшаяся 30 июня 1948 года в тех же Bell Labs (сам прибор был изобретён Бардином, Браттейном и Шокли несколькими месяцами раньше, 16 декабря 1947-го). Однако Шеннон, по Глику, «глубже и фундаментальнее», чем транзистор.

Журнал Scientific American назвал работу Шеннона «Великой хартией информационной эпохи» (Magna Carta — английская «Великая хартия вольностей» 1215 года, документ, заложивший основы конституционного права; в современном английском это идиома, обозначающая фундаментальный, учредительный текст какой-нибудь области). Это не преувеличение.

5. Машины для радости

Если бы Шеннон ограничился вышеперечисленным, он бы остался в истории как сухарь-математик, спрятавшийся за формулами. Реальный Шеннон был совсем другой.

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

Тесей — самая знаменитая из этих игрушек. В 1950 году Шеннон собрал в лаборатории Bell механического мышонка размером с теннисный мяч, который умел проходить лабиринт. Сначала мышонок двигался случайно, натыкаясь на стенки, пока не находил «сыр» — кусочек медной фольги. На втором запуске он уже шёл к сыру кратчайшим путём. Под лабиринтом стояла схема из примерно 90 телефонных реле, которая «помнила» путь. Лабиринт можно было пересобрать — поставить перегородки в другом порядке, — и Тесей переучивался заново.

Это была одна из первых в мире демонстраций машинного обучения. ENIAC, первый программируемый электронный компьютер, на тот момент существовал четыре года и занимал большой зал. Тесей же, использующий обычные телефонные реле, помещался под столом. На YouTube до сих пор можно найти оригинальный фильм Bell Labs 1952 года, где Шеннон стоит рядом с мышкой и спокойным голосом объясняет: «Сначала мышь идёт случайно. Потом она запоминает дорогу». В современной литературе по ИИ Тесея называют «прародителем всех систем обучения с подкреплением».

Жонглирование Шеннон любил с детства, и в Bell Labs оно стало его самой узнаваемой привычкой. Он жонглировал тремя шарами, иногда — четырьмя. Больше у него не получалось, и это его огорчало. Чтобы понять, почему именно не получается, он вывел математическую формулу жонглирования: (F + D) / (V + D) = N / H, где F — время полёта шара, D — время, которое шар находится в руке, V — время, которое рука пуста, N — число шаров, H — число рук. Формула, к его искреннему удивлению, не помогла ему освоить жонглирование пятью шарами.

Моноцикл Шеннон освоил уже взрослым, в Bell Labs. И тут случилась самая известная сцена в фольклоре лаборатории: Шеннон катался по длинным коридорам исследовательского центра на одноколёсном велосипеде, жонглируя при этом тремя шарами. Колеги, которые встречались ему по пути, прижимались к стенам — никто не был уверен, остановится ли он на повороте. Никто не понимал, зачем он это делает. Спросить его боялись, потому что ответ был предсказуем: «Для удовольствия».

Ультимативная машина — устройство, которое Марвин Минский придумал в 1952 году, а Шеннон собрал. Это деревянный ящик с одним переключателем. Когда вы включаете переключатель, из ящика выползает механическая рука и выключает переключатель обратно. Ящик закрывается. Больше он ничего не делает. Артур Кларк, увидев этот аппарат на столе Шеннона, написал: «Есть что-то невыразимо зловещее в машине, единственное назначение которой — выключить саму себя».

Другие игрушки Шеннона включают: семь различных шахматных автоматов, моноцикл с эксцентрическим колесом, который катился как пьяный, прыгающую палку на пружине (такая детская игрушка с педалями и ручками, на которой подпрыгивают) — только у Шеннона эта палка имела бензиновый двигатель; нож на сто лезвий; механический манекен в виде Уильяма Клода Филдза (W. C. Fields, 1880–1946 — знаменитый американский комик и цирковой жонглёр, в США 1930-х фигура примерно того же ранга, что в СССР Юрий Никулин), жонглирующий бильярдными шарами; компьютер, считающий в римских цифрах (Шеннон шутил, что мечтал «увидеть римлянина с настоящим калькулятором»); Кубик Рубика, который собирала отдельная машина; пенопластовые тапочки, в которых можно ходить по воде через озеро у дома (его жена Бетти подтвердила, что они работали).

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

6. Бетти, дом на озере Мистик

В 1948 году, в год выхода той самой статьи про теорию информации, Шеннон познакомился в Bell Labs с молодой коллегой — Мэри Элизабет «Бетти» Мур, программисткой и аналитиком. Они поженились в 1949 году.

Бетти оказалась не «женой великого человека», а полноценным интеллектуальным партнёром. Она и сама была математиком: до Bell Labs работала в Bell Aircraft на численных расчётах, потом в Bell Labs — на ранних программируемых калькуляторах. Когда Шеннон строил Тесея, Бетти помогала ему паять реле. Когда он писал статьи, она их редактировала и часто находила в них ошибки и неудачные формулировки. В их доме на берегу озера Мистик в Винчестере, штат Массачусетс, куда они переехали в 1956 году, был не один общий рабочий стол, а несколько.

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

В одном эпизоде Шеннон и его друг Эдвард Торп (математик, придумавший подсчёт карт в блэкджеке) построили первый в истории носимый компьютер — устройство размером с пачку сигарет, которое прятали под одеждой и которое предсказывало, куда упадёт шарик в рулетке в казино. Они поехали в Лас-Вегас и заработали приличные деньги. Шеннон по характеру был не игрок — ему было любопытно, может ли вообще такая машина работать. Когда выяснилось, что может, интерес Шеннона ушёл. Он подарил устройство Торпу и больше в казино не ходил.

Жил он спокойно, выступал редко, журналистам давал интервью с большой неохотой. Когда писатель Джон Хорган в 1990-х добился встречи с ним, Шеннон, к тому времени уже больной, показывал гостю свои механические игрушки, как ребёнок показывает взрослому любимые поделки. Хорган позже написал воспоминания об этой встрече — это один из самых трогательных текстов о Шенноне, который у нас есть.

7. Альцгеймер и тихий уход

В начале 1980-х близкие заметили, что Шеннон стал забывать имена и события. Через несколько лет диагноз был поставлен формально: болезнь Альцгеймера. К моменту, когда диагноз был ясен, Шеннону было около семидесяти.

Болезнь развивалась медленно, но неумолимо. Бетти ухаживала за ним дома, насколько могла. К концу 1990-х он уже не узнавал своих коллег и не помнил, что когда-то писал статьи.

Главная горечь этого ухода в том, что именно в эти годы случилось всё то, для чего Шеннон создал фундамент. В 1989-м появился веб. В 1995-м — массовый интернет. В 1998-м — Google. В 1999-м — Wi-Fi и DSL, оба построенные на алгоритмах, асимптотически приближающихся к пределу Шеннона. В 2000-м — MP3, ZIP, DivX, JPEG, и каждый из этих алгоритмов сжатия упирается в шенноновскую энтропию источника, больше которой данные сжать без потерь невозможно (это вторая большая теорема из той же его статьи 1948 года). И всё это — прямое следствие одной его статьи, написанной полвека назад.

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

Биограф Шеннона Джимми Сони в книге A Mind at Play пишет об этом с тихой грустью: «Если бы Шеннон оставался в ясном уме до самой смерти, он увидел бы, как интернет переменил мир, и понимал бы, какую роль в этом сыграла его работа. Он осознал бы успехи искусственного интеллекта, которые сделали возможным Deep Blue. У него было бы чувство, что у этого всего есть будущее. Альцгеймер лишил его этого знания».

Клод Шеннон умер 24 февраля 2001 года в доме престарелых в Медфорде, Массачусетс. Ему было 84. Бетти пережила его и дожила до 2017 года.

8. Почему его так мало знают

Эйнштейн известен потому, что был интересный в общении, дружил с журналистами и не отказывался от микрофона. Тьюринг известен своей трагической судьбой и яркой военной историей. Фейнман известен потому, что любил рассказывать истории о себе и оставил мемуары. Хокинг известен потому, что был визуально узнаваем и писал популярные книги.

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

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

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

При этом несколько лет уже идёт системная работа по возвращению Шеннона публике. Каждый год на ML-конференциях кто-нибудь вспоминает Тесея как первого ИИ. В 2017-м вышла биография Шеннона авторства Джимми Сони, неожиданно ставшая популярной. В 2016-м, к столетию Шеннона, MIT, Bell Labs и IEEE провели большую серию мероприятий. В Quanta Magazine в 2020-м был очень хороший очерк, пересказывающий его теорию для широкой аудитории. Постепенно его начинают узнавать. Но всё ещё не так, как он заслуживает. Отчасти потому, что он сам этого не хотел.

9. Финал

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

Вместо этого он жонглировал на моноцикле, паял мышонка с женой, подсчитывал карты в Лас-Вегасе ради эксперимента, строил кубик Рубика, который собирался сам, потому что было любопытно. Тихо жил в доме у озера, играл на кларнете и кормил кошек.

Но при этом — походя, в перерыве между делами, — придумал теорию, без которой не было бы ни одного гигабайта в вашем телефоне, ни одного килобита в вашей Wi-Fi-сети, ни одного бита из тех, что прямо сейчас приносят вам этот текст с сервера на экран.

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

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

— Соломон Голомб, математик и коллега Шеннона.

Шеннон не согласился бы. Он бы пожал плечами, сел на моноцикл и уехал по коридору Bell Labs, посвистывая, и жонглируя тремя шарами.

Источники

Soni J, Goodman R. A Mind at Play: How Claude Shannon Invented the Information Age. Simon & Schuster, 2017. Полноценная биография Шеннона, на которую опирается основная часть фактов в посте.
Shannon CE. A Symbolic Analysis of Relay and Switching Circuits. MS Thesis, MIT, 1937. Та самая магистерская — оцифрованный архив MIT, читать можно прямо в браузере.
Shannon CE. A Mathematical Theory of Communication. Bell System Technical Journal, 27 (1948): 379–423 и 623–656. Оригинальная статья 1948 года, всё ещё читается удивительно ясно.
Shannon CE. Communication Theory of Secrecy Systems. Bell System Technical Journal, 28 (1949): 656–715. Криптографическая работа, написанная во время войны.
Hartnett K. How Claude Shannon’s Information Theory Invented the Future. Quanta Magazine, 2020. Лучшее популярное изложение теории информации, доступное онлайн.
Horgan J. My Meeting With Claude Shannon, Father of the Information Age. Личные воспоминания Хоргана о встрече с уже больным Шенноном в 1990-х.
Claude Shannon: Tinkerer, Prankster, and Father of Information Theory. IEEE Spectrum, 2016. Подборка эксцентричных изобретений Шеннона к его столетию.
Theseus the Maze-Solving Mouse, 1952. Cyberneticzoo.com — техническое описание и фотографии оригинального устройства, плюс ссылки на видео Bell Labs.
MIT News: «MIT Professor Claude Shannon dies; was founder of digital communications». Официальный некролог MIT 2001 года.

Пять порций в день

2026-05-26T09:51:09.240Z

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

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

В этом посте расскажу, как калифорнийская маркетинговая кампания за три года превратилась в общенациональную программу США, а потом в международный стандарт от ВОЗ, почему британский Минздрав 2003 года вынужден был задним числом придумать определение «порции», которого до этого не было, что на самом деле показывают современные метаанализы, и почему сама идея «порции», как и американская привычка мерить муку «чашками» — историческое недоразумение, которое мы продолжаем тащить за собой по непонятной инерции.

I. Сакраменто, 1988: онкологи штата плюс индустрия овощей

К концу 1980-х американская онкология всё чаще говорила о роли питания в профилактике рака. В обзорах National Cancer Institute (NCI) к 1986–1988 годам уже было сведено достаточно эпидемиологических данных, показывающих обратную связь между потреблением свежих овощей и фруктов и частотой ряда онкологических заболеваний (особенно ЖКТ, лёгких, гортани). Идея была не нова, она восходит ещё к работам Дениса Бёркитта 1970-х о роли клетчатки. К концу 80-х накопилось достаточно работ, чтобы поставить вопрос: а сколько всё-таки овощей и фруктов надо съедать?

В 1988 году Министерство здравоохранения штата Калифорния запускает программу под названием «5 a Day — for Better Health» — «5 в день — для лучшего здоровья». Лозунг придуман маркетологами, а не учёными. Логика была не «вот наука доказала, что 5 порций оптимально», а «вот аккуратное круглое число, которое легко запомнить, легко произнести, удобно напечатать на плакате и разместить рекламу в супермаркете».

Партнёром выступила Produce for Better Health Foundation (PBHF) — некоммерческий маркетинговый фонд, представляющий интересы американской фруктово-овощной индустрии. Их интерес был финансовый: больше американцев покупает овощи и фруктов — больше выручка у производителей и сетей. Объединение государственного здравоохранения и отраслевого маркетинга оказалось эффективным: программа быстро попала в супермаркеты в виде ценников и наклеек, в рекламные ролики, в школьное меню.

В 1991 году программа выходит на федеральный уровень. National Cancer Institute и Produce for Better Health Foundation подписывают общенациональное партнёрство и масштабируют «5 a Day» на всю страну. К программе подключаются USDA, CDC, Американское онкологическое общество, ассоциации производителей, фитнес-блогеры и тогдашние «инфлюенсеры». В 1993 году NCI финансирует девять региональных исследовательских проектов по внедрению программы — в школах, церквях, на рабочих местах, в общинных центрах. К 1995-му «5 a Day» уже знает любой американский школьник.

Важно отметить, что число «5» никогда не было результатом эпидемиологического расчёта. Это маркетинговая величина. Авторы программы открыто пишут в публикациях середины 1990-х: цель состояла в том, чтобы дать публике «простое, понятное, измеримое число, которое легко запомнить». Что бы наука ни показывала про реальный дозо-эффект, цифра должна была быть круглой и достижимой. Пять порций — это что-то, что среднестатистический американец, ранее съедавший две порции, может представить. Десять — нет.

К 2000-м американская версия программы расширилась до «5 to 9 servings» — пяти-девяти порций (для более активных людей и определённых возрастных групп). Само число 5 при этом сохранилось как нижняя граница, как минимальный порог, как «пропуск в зону здоровья». На плакатах и в массовом сознании осталась именно «пятёрка».

II. Лондон, 2003: NHS подхватывает и задним числом определяет, что такое «порция»

К концу 1990-х американский лозунг «5 a day» по дипломатическим и научным каналам попадает в Европу. В 2000 году британский NHS Plan включает планируемую кампанию «5-A-Day» как один из приоритетов общественного здоровья. Реальная программа стартует зимой 2002–2003 года и быстро становится одной из самых узнаваемых публичных кампаний британского здравоохранения.

В этот момент возникает любопытная инженерная задача. Американская формулировка «5 порций» опиралась на американское понимание «порции» (servings), которое в США отчасти регулируется FDA для маркировки продуктов, отчасти — кулинарной традицией. У британцев никакого подобного определения не было. Откуда взять цифру?

NHS разрешает задачу через простую арифметику. ВОЗ к этому моменту официально рекомендует не менее 400 г овощей и фруктов в сутки для снижения риска сердечно-сосудистых заболеваний, инсульта и ряда видов рака. Делим 400 на 5 — получается 80 граммов. Это и становится официальным британским определением «порции»: 1 порция = 80 г.

На базе этих 80 граммов NHS строит подробный справочник того, что считается одной порцией:

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

С тех пор именно британское определение — 1 порция = 80 г — стало международным стандартом де-факто. Его использует российский Роспотребнадзор, ВОЗ в официальных коммуникациях и большая часть европейской диетологии.

III. Что такое «порция» и почему дурацкие «чашки» в рецептах — того же поля ягода

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

Возьмём ту же британскую методичку. С одной стороны, в ней зафиксировано аккуратное «80 г». С другой — справочник, переведённый на русский какой-нибудь сетью супермаркетов или фитнес-приложением, выдаёт: «одно среднее яблоко». Но «среднее яблоко» — это какое? Яблоко сорта голден весит 130–180 г, польское голден делишес — 200 г, ранетка с подмосковной дачи — 70 г, антоновка из бабушкиного погреба — 300 г. Между минимумом и максимумом — четырёхкратная разница. Какое из них «среднее», и как с этим жить?

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

И эта проблема присутствует в каждой популярной диетологической рекомендации, в каждом приложении для подсчёта калорий, в каждой инструкции на упаковке. «Употреблять 2–3 порции молочных продуктов в день», «съедайте порцию белка с каждым приёмом пищи», «детям до года — порция овощного пюре». Сколько это в граммах, почему-то не указывается. Считается, что читатель сам должен догадаться. Меня это безумно бесит.

Ещё один пример подобного идиотизма в кулинарии — американская привычка мерить ингредиенты чашками. «1 чашка муки», «½ чашки сахара», «2 чашки воды». Эта система — личный кошмар каждого, кто пытается готовить по американскому рецепту вне США. Чашка муки — это сколько в граммах? Зависит от того, просеивали вы муку перед тем, как насыпать, или нет, утрамбовали или нет, какая у вас мука — обычная, цельнозерновая, рисовая (плотности у них разные). Какая у вас чашка — фирменная мерная (236 мл) или обычная кофейная (160–200 мл)?

У этой американской странности тоже есть конкретное место и время рождения. В 1896 году в Бостоне выходит The Boston Cooking-School Cook Book — книга американской поварихи и педагога Фанни Фармер (Fannie Merritt Farmer). До этого американские рецепты вообще не содержали внятных количеств: было что-то типа «добавьте кусок масла размером с яйцо», «соли — сколько надо», «муки — чтобы тесто было правильным». Фармер впервые в массовой американской кулинарии вводит точные объёмные меры: чашки, столовые ложки, чайные ложки, обязательно «вровень с краем». Книга расходится тиражом 360 000 экземпляров при жизни автора и устанавливает стандарт, который США тащат за собой до сих пор.

Это, конечно, был большой шаг вперёд для того времени: до 1896-го американская домашняя кухня была вообще лишена количественной строгости. Но к концу XX века весь мир кроме США и Канады перешёл на килограммы и граммы, потому что для сыпучих продуктов вес объективен, а объём с поправкой на плотность, утрамбовку и температуру — нет. Но американская кулинария так и осталась в плену чашек и столовых ложек, фиксированных кулинарной школой 1896 года.

Параллель с «5 порциями» прямая: и там, и там зафиксирована формула, которая выглядит конкретной — есть же число, — но на практике опирается на культурную интуицию: что такое «порция» или «чашка», каждый понимает по-своему). И там, и там переход на нормальную метрику решает проблему: «400 г в сутки» вместо «5 порций» — это вполне понятно и не допускает разночтения. «250 г муки» вместо «1 чашки муки» — тоже. А идиотские «порции» и «чашки» — это невнятные единицы измерения, в которых легко прятать любую неточность.

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

Поэтому если вы хотите следовать рекомендации не на словах, а по делу, держите в голове 400 г, а не «5 порций». Граммы можно прикинуть на глаз, а порции — нет.

IV. Что на самом деле говорит наука: Aune 2017 и кривая, которая выходит на плато

К моменту, когда рекомендация «5 a day» стала глобальной кампанией, наука накопила достаточно данных, чтобы посмотреть на сам вопрос строже: а сколько граммов всё-таки действительно нужно съедать, чтобы быть здоровым?

В 2017 году в International Journal of Epidemiology вышел крупнейший на тот момент метаанализ по теме под руководством Даги Эуне (Dagfinn Aune), норвежского эпидемиолога из Имперского колледжа Лондона. Объединены результаты проспективных когортных исследований, в которых наблюдалось в общей сложности более двух миллионов человек. Изучаемые показатели: сердечно-сосудистая смертность, онкология, общая смертность.

Главные результаты:

есть явная обратная связь между потреблением овощей и фруктов и риском сердечно-сосудистых событий, общей смертности и (в меньшей степени) онкологии;
дозо-зависимый эффект прослеживается вплоть до 800 г в сутки (примерно 10 порций по британскому стандарту), но большая часть пользы достигается на первых 4–5 порциях;
по оценке авторов, если бы всё население земного шара съедало по 800 г овощей и фруктов в день, можно было бы предотвратить порядка 7,8 миллиона преждевременных смертей в год;
между фруктами и овощами есть нюансы: овощи (особенно зелёные листовые и крестоцветные) дают чуть больший эффект, чем фрукты, в пересчёте на грамм;
разнообразие важно: широкий набор разных видов работает лучше, чем большие количества одного-двух.

Из этих данных следует две вещи. Во-первых, рекомендация ВОЗ «не менее 400 г в сутки» — это нижняя планка, входной билет в зону снижения риска. Это не «идеал», а «приличный минимум». Если есть возможность съедать 500–600 г, эффект будет ещё лучше. Если 800 г — ещё чуть-чуть лучше.

Во-вторых, кривая выходит на плато. Польза не растёт линейно. Если вы уже едите 5 порций в день (400 г), переход на 10 порций (800 г) даст вам небольшое улучшение, но это меньший прирост, чем переход с одной порции на пять. Это типичная для биологии «убывающая отдача»: первые сдвиги дают максимум, дальше — всё медленнее.

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

Иначе говоря, наука по этой теме говорит примерно так:

ешьте 400–800 г разных овощей и фруктов в день;
первые 400 г — самые важные;
больше — лучше, но не в разы;
пользу приносят цельные продукты, а не БАДы.

Никакого сакрального числа «5» в этой картине нет. Есть просто масса овощей и фруктов в граммах.

V. Россия: 400 г есть, но в граммах, а не в порциях

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

не менее 400 г в сутки свежих овощей, фруктов, ягод и зелени (некрахмалистых — то есть без картофеля);
сверх того — 250 г картофеля и 280 г фруктов в детализированных нормах приказа Минздрава России № 614 от 19 августа 2016 г.;
400 г — это «оптимальная и при этом предельная» норма, без надобности перегружаться сверху.

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

В массовой же культуре «5 порций» работает примерно так же, как в Великобритании: запоминается легко, выполняется плохо. По разным оценкам, реальной нормы 400 г в России достигают около 15–20 % взрослого населения. В Великобритании, где кампания идёт уже 20+ лет, — около 27 %. То есть даже в стране-родоначальнице большинство людей рекомендации не выполняют. Лозунг закрепился в культуре, поведение почти не изменилось.

VI. Что с этим делать

Если собрать всё вышесказанное, получается такая картина.

Первое. «5 порций овощей и фруктов в день» — это маркетинговая упаковка для рекомендации ВОЗ «не менее 400 г в сутки», придуманная в Калифорнии в 1988 году в партнёрстве здравоохранения и фруктово-овощной индустрии. Число «5» в этой рекомендации для запоминаемости, никакой магии и никакой науки.

Второе. Реальный ориентир — 400 г разных овощей, фруктов, ягод и зелени в сутки (некрахмалистых — без картофеля). Картофель — отдельная категория, в счёт «овощей и фруктов» по международным стандартам не идёт.

Третье. Старайтесь не считать в порциях, а прикидывать в граммах. Среднее яблоко — около 150–180 г, банан — 120 г, плотная горсть черники — 100 г, тарелка нормального салата — 150–200 г. Если вы съели два яблока, тарелку овощного салата и горсть ягод, вы уже выполнили норму.

Четвёртое. Эффект усиливается с разнообразием. Замените повседневный «помидор-огурец-помидор» на регулярную ротацию: брокколи, шпинат, морковь, болгарский перец, тыква, зелёные листовые, бобовые, ягоды, цитрусовые, яблоки, груши. Польза идёт от пакета веществ, а не от одного-двух «суперпродуктов».

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

Шестое. БАДы и поливитамины не заменяют цельные овощи и фрукты. Эпидемиология показывает, что таблетка витамина С или добавка с антиоксидантами не воспроизводят эффект цельного рациона. Работает «весь пакет» — клетчатка, полифенолы, влияние на микробиоту, плюс простое замещение в тарелке других, менее полезных продуктов.

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

VII. Финал

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

Тем не менее, под обёрткой имеются вполне научные обоснования. Метаанализ Эуне 2017 года на двух миллионах человек показывает, что 400–800 г овощей и фруктов в сутки реально снижают риск сердечно-сосудистых событий, общей смертности и онкологии, и что львиная доля этой пользы достигается именно на первых 4–5 порциях. То есть рекомендация по сути правильная, просто упакована в странную единицу измерения.

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

Использованные исследования и источники

Foerster SB, Kizer KW, Disogra LK et al. California’s “5 a Day — for Better Health!” Campaign: An Innovative Population-Based Effort to Effect Large-Scale Dietary Change. American Journal of Preventive Medicine, 1995. — обзор калифорнийской кампании-родоначальницы.
Heimendinger J et al. 5 A Day for Better Health — Nine Community Research Projects to Increase Fruit and Vegetable Consumption. Public Health Reports, 1995. — отчёт о федерализации программы.
Aune D, Giovannucci E, Boffetta P et al. Fruit and vegetable intake and the risk of cardiovascular disease, total cancer and all-cause mortality — a systematic review and dose-response meta-analysis of prospective studies. International Journal of Epidemiology, 2017. — главный современный метаанализ темы на двух миллионах человек.
WHO. Healthy diet. Информационный бюллетень ВОЗ, в котором закреплено «не менее 400 г фруктов и овощей в сутки».
NHS UK. 5 A Day: what counts? — официальный британский справочник «что считается одной порцией 80 г».
Роспотребнадзор. 400 г в день: как есть больше овощей и фруктов. — российская трансляция рекомендации ВОЗ.
Приказ Минздрава России № 614 от 19 августа 2016 г. Рациональные нормы потребления пищевых продуктов, отвечающие современным требованиям здорового питания.
Farmer FM. The Boston Cooking-School Cook Book, 1896. — историческая отправная точка американских кулинарных «чашек».