Открытый исходный код принято считать территорией без границ. Код либо хороший, либо нет. Политика сюда не вмешивается. Так было принято думать. История процессора Baikal-T1 показывает, что это давно не так.
Пять лет в ядре и тихое исчезновение
Начиная с ветки 5.8 российский процессор Baikal-T1 существовал в ядре Linux официально: драйверы контроллеров, поддержка интерфейсов, интеграция платформы. Это не экзотика — это признание со стороны одного из крупнейших в мире программных проектов.
Теперь этого признания нет. В версии 7.0 исчезли драйверы i2c и spi dw. В версии 7.1 удалены поддержка контроллеров AHCI SATA и PCIe. На очереди — драйверы таймера, памяти, physmap, шины, hwmon, dwc и bt1-rom. Когда процесс завершится, от платформы Baikal в актуальном ядре не останется ничего.
Официальная формулировка — отсутствие сопровождения и незавершённая интеграция. Драйвер PCIe так и не был доведён до рабочего состояния. Всё верно. Но почему не был доведён — вот настоящий вопрос.
Санкции заблокировали участие в разработке
С 2023 года сообщество разработчиков Linux прекратило принимать патчи от «Байкал Электроникс». Причина — санкции США. Линус Торвальдс поддержал это решение. Имена разработчиков, связанных с Россией, исчезли из файла MAINTAINERS — документа, определяющего, кто отвечает за каждый компонент ядра.
Без сопровождающих патчи не принимаются. Без патчей код стоит на месте. Стоящий код деградирует относительно остального ядра и в итоге признаётся неподдерживаемым. Формально — техническое решение. По существу — прямое следствие политического.
Производство встало ещё раньше
Программная часть истории началась позже физической. Производство микросхем Baikal на мощностях TSMC остановилось в 2022 году — сразу после введения санкций. Попытка найти выход через корпусирование Baikal M на калининградском GS Nanotech закончилась в ноябре 2025 года: кристаллов попросту не осталось.
Нет производства — нет новых изделий. Нет новых изделий — нет смысла развивать платформу. Нет развития — нет сопровождающих. Цепочка логична и безжалостна.
Что представлял собой процессор
Baikal-T1 — промышленная микросхема, а не попытка конкурировать с серверными процессорами. Два ядра MIPS P5600 на частоте 1,2 ГГц, контроллер DDR3-1600 ECC, порт 10Gb Ethernet, пара портов 1Gb Ethernet, PCIe Gen.3 x4, два порта SATA 3.0 и аппаратный криптоускоритель с поддержкой отечественного алгоритма ГОСТ 28147-89.
Целевые применения — промышленная автоматика, телекоммуникационное оборудование, встраиваемые системы. Там, где не нужны терафлопсы, но важны надёжность, предсказуемость и отечественное происхождение. В своей нише процессор был вполне состоятельным решением.
Два уровня зависимости — оба оборваны
История Baikal обнажила структурную проблему, выходящую за рамки одного процессора. Российская микроэлектроника оказалась уязвима одновременно на двух уровнях, которые принято считать независимыми:
- Первый — производственный. Без доступа к современным полупроводниковым фабрикам выпуск чипов невозможен. TSMC закрылась по санкционным требованиям, внутренних альтернатив нужного техпроцесса нет.
- Второй — программный. Участие в открытых проектах уровня Linux требует присутствия в глобальном сообществе. Санкции отрезали и этот канал: патчи не принимаются, разработчики вычеркнуты из списков сопровождающих.
Оба уровня считались относительно независимыми от политики. Оказалось — нет.
Что дальше для тех, кто уже работает на Baikal
Встроенные системы на Baikal-T1 никуда не денутся мгновенно — железо продолжает работать. Но выбор у их операторов невелик: либо оставаться на замороженных LTS-версиях ядра и принять, что обновления безопасности со временем прекратятся, либо мигрировать на другую платформу с сопутствующими затратами.
Ни тот, ни другой путь не назовёшь удобным. Особенно для промышленных систем с длинным жизненным циклом, где замена процессорной платформы — это не обновление драйвера, а полноценный инженерный проект.
Вопрос, который встаёт за этой историей в полный рост: возможно ли создать российскую процессорную платформу с устойчивой поддержкой в открытых экосистемах при нынешних ограничениях — или путь через собственные закрытые программные стеки становится единственной реалистичной альтернативой?