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

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

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

Комсомольцы, героически создают себе "очень сложные для решения" проблемы на ровном месте. Если бы, как у всех остальных, была бы кроме ядра ОС в целом, т.е. базовая система (с glibc и прочей теснозависимой системщиной) - она бы находилась в согласованном состоянии, этих сложностей бы и не возникало.