
Все так и есть. Разработчики ядра Linux прекращают поддержку устаревших процессоров уровня Intel 486 — архитектуры, на которой держались домашние ПК начала 90-х. Линус Торвальдс начинал разработку Linux в 1991 году на процессоре Intel 386, а потом ОС широко распространилась на более массовых тогда машинах с 486 чипами. Сегодня от этой совместимости отказываются: она усложняет код ядра и мешает внедрять современные оптимизации и механизмы безопасности.
Старые компьютеры продолжат работать, катастрофы нет. Но вот новые версии Linux на них уже не запустятся. i486 давно не соответствует требованиям актуального ПО, а реальных пользователей таких систем почти не осталось. Проект окончательно смещает фокус на современные многоядерные процессоры, а 486-й уходит в историю как одна из ключевых платформ ранней эпохи Linux. Давайте разбираться, что здесь и как.
Долгий путь процессоров 486 в Linux
Чипы серии 486, появившиеся в 1989 году, быстро стали стандартом для домашних и офисных ПК благодаря заметному приросту производительности по сравнению с предыдущим поколением и появлению встроенных возможностей для более сложных вычислений. Именно поэтому поддержка этой архитектуры сохранялась в ядре Linux на протяжении десятилетий: система развивалась как максимально универсальная платформа, рассчитанная на широкий спектр оборудования — от самых простых до более производительных машин.
Со временем такие чипы ушли в разряд музейной техники, хотя отдельные системы на их базе продолжали использоваться в нишевых проектах и у энтузиастов. При этом Linux сохранял поддержку не только оригинальных процессоров Intel, но и их клонов от AMD, Cyrix и других производителей, включая версии без встроенного математического сопроцессора. Для этого в ядре долгое время поддерживались специальные механизмы и обходные решения, учитывающие особенности каждой такой конфигурации и обеспечивающие стабильную работу.

Однако поддержка требовала постоянных усилий от команды. По мере того как в ядре появлялись более современные функции, старые процессоры начинали выделяться как источник дополнительных сложностей. Разработчики все чаще сталкивались с ситуациями, когда усилия на совместимость отвлекали от решения задач, связанных с новыми архитектурами, безопасностью и производительностью.
В итоге сообщество пришло к выводу, что дальнейшее сохранение полной совместимости не оправдывает затрат. Это решение созревало постепенно и опиралось на многолетние обсуждения в списках рассылки. Теперь оно воплощается в конкретных изменениях кода.
Что именно меняется в версии ядра 7.1
Первый серьезный шаг сделал Инго Молнар, опытный разработчик ядра, чей патч уже попал в очередь на слияние для выпуска 7.1. Из системы сборки убираются опции CONFIG_M486, CONFIG_M486SX и CONFIG_MELAN. Эти настройки раньше позволяли собрать ядро под 486DX, 486SX без сопроцессора и специализированные чипы AMD Elan.
После патча собрать образ, ориентированный именно на 486 чип, станет технически невозможно. Пользователи больше не смогут получить работоспособное ядро для такого железа без дополнительных модификаций исходников. Это только начало, и в следующих версиях планируется полная очистка оставшегося кода.
Изменения затронут не только файлы конфигурации. В дальнейшем разработчики намерены удалить значительные фрагменты, связанные с эмуляцией определенных инструкций. Такой подход позволит сосредоточить силы на современном минимальном уровне процессоров, начиная примерно с Pentium и выше.
Новый порог совместимости требует наличия счетчика меток времени и инструкции 64-битного сравнения с обменом. Без этих возможностей ядро просто не соберется под старое железо. Патч уже находится в ветке tip.git и ожидает слияния в ближайшем окне.
Цена совместимости: почему разработчики решили избавиться от устаревшего кода
Поддержка старых 32-разрядных x86-процессоров требовала от ядра дополнительных обходных решений: часть операций, которых у этих чипов нет, приходилось реализовывать программно. Это усложняло код и мешало развитию, а заодно иногда вызывало ошибки при работе на современном оборудовании.
Специалисты тратили время на исправление проблем, которые проявлялись исключительно на редких старых системах. Линус Торвальдс еще несколько лет назад заявил, что нет никакой практической необходимости продолжать тратить ресурсы на все это. По его мнению, каждую секунду, потраченную на такую совместимость, лучше направить на оптимизацию тех частей системы, которыми пользуется большинство.
Инго Молнар в описании своего патча отметил, что накопившиеся за годы обходные решения и специальные ветки кода, добавленные ради поддержки устаревших процессоров, все чаще создают новые сложности вместо того, чтобы их устранять. То, что раньше помогало сохранять совместимость, со временем превратилось в источник лишних проблем и потенциальных ошибок. В результате в комьюнити сформировалось общее понимание: пришло время избавиться от этого наследия и упростить кодовую базу, сосредоточив усилия на архитектурах, которые действительно используются в современных дистрибутивах.
Предложение об удалении поддержки появилось еще в 2025 году в виде серии патчей RFC. С тех пор обсуждения продолжались почти год, и в итоге выбрали поэтапный подход. Сначала убирают опции сборки, а потом можно спокойно вычистить остатки без риска сломать что-то важное.
Как удаление кода повлияет на развитие ядра
Полная очистка затронет около 80 файлов и позволит избавиться более чем от 14 000 строк legacy-кода. Среди прочего исчезнет целая библиотека math-emu, которая полностью имитировала работу математического сопроцессора для чипов без встроенного FPU. Это заметно упростит некоторые внутренние функции и сделает исходники понятнее для новых участников разработки.
Ядро сможет отказаться от избыточных проверок и условных веток, связанных с поддержкой устаревших CPU, а также от вспомогательных оберток и fallback-реализаций. Это сократит количество специальных случаев в коде, упростит критические участки и снизит накладные расходы. В результате внедрение новых возможностей, оптимизаций и механизмов безопасности ускорится и будет требовать меньше компромиссов, позволяя разработчикам сосредоточиться на актуальных архитектурах и реальных сценариях использования.
Такое решение отражает общую тенденцию в open-source-проектах: время от времени избавляться от мертвого груза, чтобы система оставалась живой и динамичной. Аналогичный шаг был сделан в 2013 году с процессорами 386, и тогда это тоже прошло относительно спокойно для сообщества. Теперь история повторяется на новом витке.
В долгосрочной перспективе упрощение кода положительно скажется на стабильности и производительности. Разработчики смогут быстрее реагировать на уязвимости и внедрять современные технологии без оглядки на древнее железо. Это особенно важно в эпоху, когда даже минимальные требования к системам продолжают расти.
Что еще…
Для любителей ретротехники это изменение знаменует собой конец целой эпохи. Машины на оригинальных 486-процессорах больше не смогут загружать свежие версии ядра из основного дерева разработки. Энтузиастам придется оставаться на долгосрочных поддерживаемых релизах, которые еще несколько лет будут получать обновления безопасности и исправления.
Многие такие системы уже давно используются в изолированной среде или для специфических хобби-проектов вроде запуска игр и софта прошлых лет. Владельцы могут продолжать экспериментировать со старыми дистрибутивами, где поддержка 486 сохраняется в полной мере. Никто не требует немедленно переходить на новое оборудование или отказываться от любимых машин.
Некоторые более поздние и специализированные чипы, формально относящиеся к тому же семейству x86, сохранят совместимость, поскольку поддерживают необходимые инструкции. Ограничения затрагивают только самые ранние и функционально урезанные процессоры. При этом для энтузиастов ретросистем ситуация не станет неожиданностью: старые версии ядра и альтернативные решения по-прежнему позволяют использовать такое оборудование.
Комментарии (16)

arteast
14.04.2026 07:41This series increases minimum kernel support features to include TSC and CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) support and early-586 (and derivatives) support. Much of which is the math-emu/ library - but even without math-emu, the simplification is substantial.
Я не знаю, насколько мешало отсутствие нативного CX8 (вряд ли сильно), а вот потенциальное отсутствие TSC может мешать.

unreal_undead2
14.04.2026 07:41В принципе compare exchange на два слова полезен во всяческих lock free структурах.

arteast
14.04.2026 07:41Несомненно полезен. Нативного - ключевое слово. В отсутствие нативного 8-байтного cmpxchg он эмулируется через cli+неатомарный xchg+popf (что можно делать только для Uniprocessor и при отсутствии NMI, но в 486 SMP - это экзотика и возможно что вообще не поддерживается в современном линукс?). В общем, этот код уже есть, он спрятан в паре файлов, при поддержке CX8 эмуляция выпатчивается в единственную инструкцию и т.д. - в общем особо не должно мешать.
А вот отсутствие TSC - это хрень, которая может "заражать" код в разных местах. Хотя на первый взгляд и не выглядит, что
CONFIG_X86_TSCи иже с ним разбросано по 100500 местам.
unreal_undead2
14.04.2026 07:41Работа с TSC по идее тоже должна быть локализована, всё таки кроме вариаций x86 надо и другие архитектуры поддерживать.
unreal_undead2
Так всё таки какие конкретно новые фичи/инструкции Pentium часто используются в ядре (требуя заметного количества кода для совместимости с 486)?
Для 486DX оно не нужно.