Russian Fedora - сообщество русскоязычных участников международного проекта Fedora

Продолжается победное наступление systemd на дистрибутивы. Основной мэйнтейнер Lunar Linux и сотрудник Intel, работающий над проектом Tizen, Auke Kok в своей ленте Google+ анонсировал революционное изменение, которое он уже представил на рассмотрение разработчикам systemd.

Сначала, он упомянул, что Tizen также переходит с устаревшего SysV на systemd, а затем он рассказал о его нововведении, которое создано в рамках внедрения systemd инженерами Intel совместно с инженерами Samsung - первом варианте изменений, которые предназначены для управления пользовательскими сессиями не на уровне неких демонов, встроенных в Desktop Environment (gnome-session, startxfce4 и прочих), а с помощью systemd. Он добился значительного ускорения и повышенной надежности загрузки (лучший контроль компонентов).

Какова же проблема, которую он решает? Изначально, в устаревшем SysV, не было никакой возможности запустить рабочее окружение пользователя. Процесс загрузки выглядит так - init от суперпользователя запускает скрипты в /etc/init.d, затем запускает desktop manager (GDM, KDM, XDM или иные). Пользователь вводит пароль и логин, и desktop manager известным лишь ему образом запускает последовательность действий для запуска рабочего окружения (на этом этапе init уже никак не задействован). Таким образом, у нас есть минимум два компонента, которые запускают сервисы в системе - init и еще один на каждый Desktop Envionment, доступный на машине пользователя. Все это приводит к дублированию правил запуска для различных desktop manager, написанию неких менеджеров сессий и прочей лишней работе, результаты которой, к тому же, еще и содержат ошибки, порой трудноуловимые.

С появлением основанного на принципах философии Unix, специализированного изолированного компонента для запуска системы, который учитывает различные внешние события (он, как и полагается такому компоненту, делает только одно и делает это хорошо - следит за запуском и состоянием сервисов), оказалось можно отделить компоненты запуска рабочего окружения от Desktop Environment и сделать их полностью независимыми (и зависимыми от systemd, конечно). Auke написал первый прототип, который уже заслужил теплый отзыв от Greg Kroah-Hartman, оставленный им в его ленте Google+.

Что ж, вслед за уже почти закончившимся повальным переходом дистрибутивов на systemd, будем ожидать переходов Desktop Environment на него-же. А пользователям дистрибутивов, которые все еще по каким-то причинам не начали переход на systemd, стоило бы потормошить своих мэйнтейнеров.

Сегодня специалист Red Hat и участник Fedora Ben Skeggs анонсировал в своей ленте Google+ грядущие большие изменения в открытом видеодрайвере для видеокарт NVIDIA - nouveau. Основатель Phoronix Michael Larabel написал развернутую статью о том, какие-же изменения идут (и пообещал провести бенчмарки). Вкратце, результаты некоторых синтетических тестов улучшились вдвое (по заявлениям разработчиков), упала нагрузка на центральный процессор (также, пока не было независимой проверки), старый драйвер nvfx был заменен на новый nv30 (это касается видеокарт GeForce 5 (FX), 6 и 7).

К сожалению, все это требует одновременного использования самых новых libdrm, Mesa и nouveau, так-что я бы не ожидал это в Fedora 15 и Fedora 16. Будут-ли улучшения доступны в Fedora 17 - нельзя сказать определенно. С одной стороны, такое улучшение удовлетворяет критерию "более полная поддержка оборудования", с другой - требует нового API, что является блокирующим критерием для включения в стабильный релиз.

Не так давно одна из компаний, которая спонсирует известный "юзер-френдли" дистрибутив, объявила, что она переходит на OpenStack, как средство для развертывания своего облачного решения. Некоторые специалисты высказали предположение, что повторится типичная ситуация - эта компания никак или почти никак не участвует в развитии продуктов, которые использует (не тестирует, не исправляет ошибки, не добавляет функциональность), и с этой платформой будет точно то-же самое. И вот, теперь можно увидеть, были-ли они правы.

Специалист компании Red Hat и участник Fedora Mark McLoughlin собрал статистику, из которой следует, что инициативы Red Hat по включению OpenStack в Fedora принесли платформе гораздо больше изменений, чем Canonical. По их итогам Red Hat оказался третьим по размеру корпоративным разработчиком OpenStack. А ведь были еще и тестовые дни OpenStack (и совсем недавно). Конечно нельзя недооценивать 0.5 - 3% изменений, внесенных Canonical, и большое им спасибо и за это, но нельзя и не отметить, что это непропорционально мало по сравнению с шумом в прессе. Впрочем как и обычно. Еще один нюанс - в отличие от Canonical, на текущий момент Red Hat не предоставляет коммерческой поддержки OpenStack в своих продуктах, хотя ходят слухи, что будет предоставлять.

В Fedora принята довольно строгая политика по отношению к библиотекам - если приложение требует какую-либо библиотеку, то оно должно использовать ту копию, которая присутствует в репозитории, а не ту, что разработчик приложения запихнул в tarball. Чтоб добиться этого, мэйнтейнер, проводящий аудит пакета (Review), обычно требует физически удалить библиотеки, дублирующие системные, из распакованных исходных текстов на этапе сборки RPM-пакета (обычно на стадии %prep). Исключения из этого правила возможны лишь с разрешения FESCo. Если-же приложение при сборке использует bundled libs, то значит кто-то недоглядел, и стоит открыть заявку в багзилле.

Некоторые потенциальные участники Fedora, а также некоторые разработчики постоянно критикуют это требование, за излишнюю (и, порой, кажущуюся искусственно созданной) сложность. Мол "в простом в настройке и использовании дистрибутиве Xxx и Yyy такого нет, и живут ведь как-то". Опять-же, в среде Java-программистов, сформирована привычка таскать все библиотеки с собой, что особенно актуально для "больших" приложений, которые пользователи скачивают со сторонних сайтов (например, NetBeans только начал свое возвращение в Fedora, и его пользователи просто вынуждены его качать откуда-то еще). Эта практика возникла не на пустом месте. Иногда разработчики вынуждены учитывать бедность репозиториев других Unix-систем (того же Mac OS X), не говоря уже об известной не-Unix проприетарной системе, где просто ничего нет из коробки. Порой разработчики застряли со старым API какой-то из библиотек и везде ее таскают за собой. Иногда-то наоборот, в репозиториях лежат слишком старые версии, а разработчики использовали какие-то новинки последних версий. Но, к сожалению, порой они включают библиотеки по привычке, просто так.

Fedora требует исключать так называемые bundled libs по нескольким причинам - мы тем самым помогаем разработчикам, проверяя работу с последними версиями библиотек, уменьшаем время сборки и размер итогового пакета, гарантируем, что исправления ошибок и дыр в безопасности сразу появятся во всех приложениях, ну и в целом создаем приятное эстетическое впечатление от системы. К сожалению, как и было уже сказано, некоторые потенциальные мэйнтейнеры ругают эту практику, кивая на маргинальные дистрибутивы, где такого правила нет. Что до аргументов о безопасности и исправлении ошибок, то они либо игнорируются, либо на них с гордо вскинутой головой отвечается, что "это не помешает нам исправлять ошибки - если что, то просто пересоберем с патчами". Ну что ж, эта самоуверенность принесла свои плоды. Давний участник Fedora, специалист по безопасности, работающий на НАТО и ЦРУ, математик, специализирующийся на формальных методах (к сожалению, подавляющая часть его работ засекречена его работодателями) и участник соответствующей Fedora Formal Methods SIG, David A. Wheeler указывает на недавний отчет от компании Aspect Security (к сожалению, он registerwalled). В отчете сообщается, что примерно 26% Java-приложений, скачанных из "основных" репозиторев, то есть именно тех, которые традиционно поставляются сразу со всеми нужными для запуска библиотеками, имеют уже известные проблемы с безопасностью. Качайте и дальше большие Java-приложения в формате ZIP, но только потом не жалуйтесь на "дырявый линукс" и не кусайте локти, что отключили SELinux, который "не нужен на десктопе" и "только мешает". Особенно эта новость актуальна всвязи с недавними сообщениями о серьезных проблемах (за февраль и за апрель) с безопасностью Java.

Немного отвлекшись сообщим, что ситуация с Java в Fedora именно потому и не очень хороша, что участники Fedora Java SIG двигаются очень медленно, тратя время на расплетение клубка bundled libraries, которые наворотили вокруг своих приложений Java-разработчики.

Итак, возвращаясь к теме - David в комментарии в своем блоге подчеркивает, что проблема приобрела такое широкое распространение из-за единственной причины - Java разработчики не выучили урока, давно усвоенного подавляющим количеством программистов на C/C++ (увы, еще не всеми) - всегда надо использовать системные версии библиотек. Он подчеркивает, что он и многие другие специалисты по безопасности уже не раз возвращались к теме bundled libs, и что приложение с кучей упакованных библиотек можно лишь расценивать, как преступную халатность и общую неряшливость команды разработки. Таская библиотеки со своим приложением, разработчик сознательно отказывается от главного преимущества OpenSource - от аудита коммьюнити. Это очень и очень трудно оправдать.

Вот почему в ведущих дистрибутивах Linux, таких как Fedora, Debian, openSUSE, тратят время на такую странную задачу - выкусывать библиотеки из tarball и собирать с уже имеющимися. Так было, есть и будет - и ныне, и присно, и во веки веков.