Гуманитарная причина одна: чтобы быть уверенным, что всё работает и ничего не сломается с таким обновлением. Технических причин несколько.Операционная система Linux не имеет инструментария динамической подгрузки модулей собранных одновременно под несколько версий ядра. Сама идея некого framework-а, обеспечивающего переносимость драйверов и других модулей на хоть сколько-нибудь вразумительный срок упирается в:
1) монолитность ядра, всё должно быть слинковано в одном ядре
2) отсутствие стандартизации ABI, его просто нет как класса
3) идеологические причины, это позволит разработчикам распространять модули и драйверы под лицензией отличной от GPL
4) отсудив объектной шины данных, если таковой, конечно, не считать netlink, или, простите, UNIX pipes.
Ванильное ядро Linux имеет крайне раздутую кодовую базу. Внутри него содержится:
- внушительное количество кода поддержки драйверов устройств, несмотря на наличие оригинальных драйверов, но под неподходящей лицензией
- поддержка заброшенных файловых систем, которая, по сути, историческая. Вообще количество ФС в ядре Linux высоко, прежде всего, потому что блочная абстракция написана из рук вон плохо. И это отдельный разговор...
- множество функциональных модулей, особенно частей сетевой подсистемы, которые прекрасно можно было бы оформить в качестве демонов в пространстве пользователя, но которые представлены как драйверы, потому что нет в Linux никакой стандартизации пространства пользователя.
- поддержка неактуальных процессорных архитектур.
Там в 2024-ом году такая вундервафля, что вспоминается детский анекдот: "Уважаемые пассажиры! В нашем самолете находится два кинозала,
бар, ресторан, детский и взрослый бассейны, библиотека, 2 теннисных корта и поле для гольфа... А теперь со всей этой хренью мы попробуем взлететь!"
И это было бы смешно, если бы не было так грустно.
Это ядро настолько сложное, что уже очень давно принято делать собственную урезанную редакцию и поддерживать её в рамках дистрибутива. При этом обновления безопасности - самая страшная боль (особенно из-за драйверов устройств).
Операционная система хоть сколько-то пригодная к установке на сервер предприятия (платная или бесплатная) должна там проработать ну хотя бы 10 лет. Ванильное ядро не поддерживает такие сроки обратной совместимости. Там даже API (святая святых!) меняют за такой срок. Поддержкой из-за этого занимаются корпорации продающие Linux, потому что Just4fun-community не способно тащить поддержку legacy ввиду отсутствия денег, отсутствия клиентов/пользователей, которым она нужна, и как следствие отсутствия денег. Это замкнутый круг. Если же этого не делать у вас сломается и перестанет работать что-то в пространстве пользователя. Не обязательно у вас лично, но у кого-то.
Компании выбирают сколько-то вменяемую версию и начинают её поддерживать несколько лет, бекпортируя не только исправления безопасности, но также и поддержку устройств, которые опять привязаны к версии ядра. Отдельно нужно понимать, что бесконечные комитеты не смогли договориться про версии... Это мрак.
Вопросы о том, что нужно бы всё-же добавить переносимость драйверов и вынести часть подсистем из ядра, озвучивались многократно. Воз и ныне там, потому что людей способных это сделать в мире Linux нету. Там люди не мыслят в архитектурном смысле. Они мыслят патчами, переживают за EXPORT_SYMBOL_GPL, устраивают мракобесные войны вокруг совместимости с другими ОС, и презирают любую стандартизацию, выбирая diversity в самом плохом смысле этого слова. Ведь проявить себя, создав собственный дистрибутив, который меняет пару дефолтных утилит и ставит нескучные обои - это разнообразие, ценность. А стандартизировать пространство пользователя, пусть даже через systemd, - жечь ведьму.
Комментаторы тут, видимо, не достаточно стары и бородаты, чтобы оценить иронию новости.
Кто бы мог подумать, что Oracle, создавшая дистрибутив в укор Red Hat, прежде всего для себя самой и своих продуктов, из вредности и для того чтобы не дать Red Hat зарабатывать деньги, спустя 15 лет объединится с теми, кто создавал открытый CentOS, чтобы абсолютно бесплатно поддерживать LTS-редакции ядра и гарантировать бесплатный доступ этого самого сообщества к хоть сколько-то стандартизированной редакции корпоративного Linux, таща на себе своими силами бинарную совместимость даже с пространством пользователя. И что туда примкнет SUSE, а Red Hat наоборот... Если бы вы 15 лет назад такое кому-то сказали, вам бы не поверили.
