В связи с недавно опубликованным заявлением о первичном приоритете сохранения неизменности внешних программных интерфейсов ядра Linux, влияющих на работу пользовательских приложений, Линусу Торвальдсу был задан вопрос, как в этом случае следует воспринимать наблюдаемые последние годы нарушающие совместимость изменения в ядре, такие как прекращение поддержки некоторых файлов и директорий в /proc, постоянное изменение структуры /sys, непостоянство механизма уведомления приложений об изменениях в файловой системе (inotify, dnotify и fnotify) и наличие в ядре API-вызовов, которые можно использовать только из модулей под лицензией GPL.

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

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

Возобновление совместимости из-за ранее внесённых ошибок рассматривается как очень сложные для решения проблемы. Например, из-за ошибки в ядре была нарушена работа 32-разрядного демона autofs при использовании 64-разрядных сборок ядра. Различные дистрибутивы добавили в свой состав разные патчи для устранения данной проблемы, но при попытке исправить проблему в ядре возникла ситуация нарушения совместимости на уровне ошибок со старыми версиями (перестали работать пакеты autofs, в которые были добавлены исправления для обхода проблемы в ядре).

Также упоминается, что многие из связанных с обеспечением обратной совместимости параметров ядра настраиваемы, поэтому можно собрать ядро с такими настройками, при которых совместимость со старыми компонентами пользовательского окружения будет нарушена. Примером таких настроек, которые легко отключается в конфигурации, может служить поддержка формата исполняемых файлов a.out, прослойка для совместимости со старым беспроводным стеком, поддержка некоторых возможностей /proc и элементы совместимости с lm-sensors. Другие параметры, влияющие на совместимость, требуют включения или отключения во время работы, например, управляющие переключением видеорежимов модули KMS должны быть отключены для старых версий X.Org, так как они мешают работе старой схемы инициализации графики.

Что касается вызовов, доступных только для модулей под лицензией GPL, то эти вызовы никогда не являлись API и относятся к категории внутренних интерфейсов ядра. Разработчики ядра никогда не утверждали, что ядром будут поддерживаться модули с лицензией отличной от основной лицензии на код ядра. Более того, многие люди утверждают, что не GPL модули использовать с ядром Linux нелегально, но юридически подобная лицензионная несовместимость пока не подтверждена в суде.

В дополнение Линус привёл пример нескольких проблем, связанных с нарушением совместимости API, с которыми ему приходится сталкиваться как пользователю Linux:

• Непостоянство программных интерфейсов драйверов, развиваемых проектом X.Org. В частности, упоминаются постоянно возникающие проблемы с разработчиками драйвера Nouveau, которые слишком часто меняют API, что приводит к несовместимости DRM-модуля Nouveau с прошлыми версиями драйвера, работающего на уровне пользователя. Тем не менее, в настоящее время отмечаются положительные сдвиги в этой области, в частности, проект Nouveau изменил свою политику и теперь пытается избегать нарушения совместимости API;
• Частое нарушение в прошлом обратной совместимости в звуковых библиотеках, развиваемых проектами ALSA и PulseAudio. Практика нарушения API в звуковых библиотеках не касалась интерфейсов ядра и в настоящее время уже почти не проявляется, тем не менее, в прошлом непостоянство звукового API приводило к большим проблемам в среде разработчиков приложений;
• Нарушение работы бинарных приложений при обновлении GLibc. Несмотря на то, что разработчики Glibc относятся к проблемам совместимости значительно более аккуратно, чем разработчики GTK+, временами случаются просчёты, приводящие к нарушению работы пользовательских приложений. При сообщении о подобных фактах нарушения работы ответом часто является ссылка на проблемы самого приложения. Хочется надеяться, что недавнее изменение модели управления в проекте Glibc позволит пересмотреть правила обеспечения совместимости.