Наши коллеги продолжают переделывать Linux, создавая полноценную платформу на базе того ПО, что уже есть. Lennart Poettering предложил сделать еще один шаг дальше и унифицировать то, как распространяется ПО.

Распространение ПО в Linux, особенно в бинарном виде, это застарелая проблема, усугубляемая любимым многими выбором из тыщи дистрибутивов. Успех таких платформ, как Android, iOS, Steam в немалой степени обусловлен жестким стандартом на API, позволяющим программировать и получать за это деньги. В традционном Linux напрограммировав что-то, разработчик с удивлением сталкивается с дикой матрицей совместимости из Libc, компиляторов и версий компиляторов, игрушечных ядер, к которым полубезумные любители юниксвэя требуют почтительного отношения, отсутствия базового функционала в init-системе, десятка библиотек на каждый use case, ни одна из которых не покрывает всех вариантов, и по которым размазывается и без того незначительный человеческий ресурс. По вопросу библиотек в очередной раз хочется отметить особо омерзительную ситуацию с криптобиблиотеками, работу по консолидации которых более-менее ведется лишь нашими коллегами в Red Hat. Заметим, что рано или поздно удастся их консолидировать, и можно смело предсказывать, какую бурную реакцию и какой поток оскорблений в наш адрес это вызовет.

Проблема выбора библиотек меркнет на фоне проблем с упаковкой, распространением, установкой и последующей поддержкой приложения. До сих пор не решена в общем случае проблема с откатом при сломанных обновлениях, с недеструктивными обновлениями, с параллельной установкой разных версий приложений. Например, при параллельной установке нескольких версий ПО, новые версии могут вносить несовместимые изменения в конфигурационные файлы, и откатить их назад (особенно в домашней директории всех пользователей в системе) может оказаться нетривиальной задачей.

Задачу обновления мы решаем на нескольких уровнях - уровень пакетов, уровень разных rootfs, уровень файловых систем. В последнем случае мы используем функциональность checkpoint-restore уровня файловой системы, и прямо сейчас, к сожалению, есть лишь один вариант - btrfs. Наши коллеги из openSUSE уже работают над задачей создания точек отката, и их вариант, Snapper, был даже поставлен на рассмотрение, как один из сценариев реализации недеструктивных обновлений в Fedora. Будет ли взят именно этот вариант, мы пока не знаем, но понятно, что способ недеструктивных обновлений будет использовать btrfs. Современные системы, такие, как CoreOS, переходят на использование btrfs, но нам немного страшновато, т.к. негативный опыт достаточно значителен. Вообще, при всем уважении к разработчикам Google, которые рекомендуют btrfs к использованию, мы бы хотели отметить, что задачи, которые они у себя решают, слабо похожи на задачи простых пользователей. Например, при ошибке файловой системы в Google клонируют машину с другой машины, перезаливая диски целиком, не глядя. Простому пользователю, при ошибке в btrfs, клонировать систему неоткуда, и хорошо, если у него есть бэкапы. Для бытового использования, функционал и параметры той же XFS превосходят и btrfs, и ext4. Есть еще вариант использовать архитектуру Unix-way, и собрать систему с транзакциями и точками отката на базе имеющегося функционала в LVM, поверх которого теоретически можно использовать что угодно, но соблазн строить систему на базе единственного компонента, а не многослойной матрешки слишком велик.

Просуммировав весь накопленный нами опыт обновления и распространения ПО, и рассмотрев альтернативные варианты (ChromeOS, CoreOS, Docker, магазины приложений в мобильных платформах), Lennart и его команда выступили с предложением использовать подразделы (sub-volume) btrfs и пространства имен (namespace) Linux (уже активно используемые в systemd и контейнерах). Его предложение уже перевели и обсуждают на OpenNET.ru. Обязательно ознакомьтесь - оно слишком большое и важное, чтоб пересказывать своими словами.

В целом, предложение разработчики восприняли с энтузиазмом. Обсуждение в ленте Google+ Леннарта Поттеринга в целом позитивное, что неудивительно т.к. высказывающихся негативно он давно всех забанил. Harald Hoyer уже начал разрабатывать обновлялку системы на базе функционала btrfs, повторяя работу отчасти проведенную в openSUSE. Другие наши коллеги взялись рассуждать о более глубинных проблемах - отсутствие стабильного API (как следствие отсутствия платформы Linux), что естественным образом порождает отсутствие стабильного ABI, на что посетовал инженер Intel, Ikey Doherty, в своей ленте Google+. Мы, конечно, придеремся - стабильный API и даже ABI в Linux есть! Это называется Red Hat Enterprise Linux. Собственно, за то, что они из тыщи разномастных компонентов собирают платформу, им и платят. Отсутствие своего видения платформы у любителей юниксвэя и их апатия к решению злободневных задач довольно заметна, и приводит к полному несоответствию популярности в интернете и в реальной жизни.

Изменения подобного плана уже назрели. Наш нынешний Fedora Project Leader, Matthew Miller, с некоторым беспокойством отмечает, что дистрибутивы просто не поспевают за тем же GitHub (он выступал на LinuxCon + CloudOpen North America 2014). Казалось бы, появление сервисов типа Packagecloud.io и внутридистрибутивных вариантов PPA должно исправить ситуацию, но нет. Пользователи не успевают оперативно собирать ПО в пакеты (не говоря уж о тестировании). А в ответ на кажущуюся излишнюю сложность пакетных менеджеров их создается тыщи, на каждый язык программирования, что приводит к хорошо видимым проблемам ненужной децентрализации.