Russian Fedora

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

Bundled libraries - немного статистики и комментариев к ней

В 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 и собирать с уже имеющимися. Так было, есть и будет - и ныне, и присно, и во веки веков.

systemd и Wayland

Это архивная статья

Keith Packard, известный разработчик X.org, фактически один из создателей X Window System, выступая на 2012 Linux Foundation Collaboration с докладом по состоянию совместимости X11 и Wayland среди прочего объявил, что планируется использовать systemd для запуска Weston, дополнения для протокола X11.

Прямо сейчас есть одно препятствие - systemd не может самостоятельно запустить X.org (он запускает xdm.service или prefdm.service), и пока они используют небольшой и грязный хак.

Также он сообщил, что X.org, запущенный под Wayland работает быстрее, чем X.org, запущенный прямо на железе. А в ответ на вопрос, будет-ли Wayland работать с аудио (старая идея о X Audio Server), он официально рекомендовал PulseAudio.

Ситуация с аудиокодеком iLBC в Fedora

Многие технологии, активно использующиеся в мультимедиа и VoIP, со всех сторон обложены софтверными патентами. Это в явном виде препятствовало их широкому распространению в OpenSource-мире, т.к. открытое ПО в основном производится в США, а там-то патенты как раз и действуют.

Причем в этом случае нельзя сказать, что это патенты на "дабл-клик", "мультитач" или "slide-to-unlock" - патентовались теоретические результаты серьезных и дорогостоящих научно-исследовательских работ. В целом сейчас ситуация в мультимедиа и VoIP стала улучшаться, так как появляются новые свободные аудио- и видеокодеки и (в основном благодаря Google) освобождаются старые.

Особняком всегда стоял отличный голосовой аудиокодек iLBC, который превосходит по показателям наглухо запатентованные аналоги от ITU-T, такие, как G.729 и почти так-же популярен среди производителей. Он всегда распространялся с исходными текстами, но под несвободной лицензией. Несмотря на наличие открытого ПО, которое его использовало, в репозитории основных дистрибутивов, оно попадало с отключенной поддержкой iLBC, что сдерживало распространение Linux, как платформы для VoIP / CoIP.

Фактически, для общения по интернет, пользователи Linux были вынуждены использовать только наиболее примитивные PCMA/PCMU и GSM аудиокодеки или использовать проприетарный Skype, который, к слову говоря, если и работал, то вполне хорошо. С распространением по-настоящему мобильной связи (телефоны на базе Linux-платформы Android или на базе iOS) и многочисленных мобильных приложений на базе библиотеки pjsip / pjmedia проблема только заострилась.

К счастью, Google в очередной раз сделал широкий жест, купив Global IP Sound, создателей iLBC, и выложив в рамках проекта WebRTC под BSD лицензией многие их разработки, в число которых попал и iLBC кодек. Участники Fedora-Legal почти сразу начали лицензионный и патентный аудит, и наконец-то сообщили нам хорошие новости - iLBC можно включать в Fedora. Пока это только означает, что от мэйнтейнеров пакетов больше не требуется предварительно модифицировать архивы с исходниками, чтоб избавиться от потенциально запатентованного ПО, но можно предположить, что недолго осталось ждать и до включения iLBC, как отдельного пакета.

Community-мероприятие 12 апреля в Москве в рамках ROSS 2012

ROSS 2012 Рада сообщить, что 12 апреля 2012 в Москве пройдет одно занимательное мероприятие. В этот день состоится Russian Open Source Summit, одна из секций которого будет ориентирована на сообщество и посвящена разработке СПО.

Если вы интересуетесь разработкой, передовыми технологиями и ведущими мировыми открытыми проектами, вам стоит прийти. И вот почему. В рамках секции планируется 4 доклада от 4 очень интересных людей. Про каждого из них хочется сказать отдельно.

Ян Вилдебоер Представитель компании Red Hat и ярый сторонник open source в жизни. Ян уже много лет работает в Red Hat и является специалистом по разработке в области открытых проектов для критически важных задач на самых разных архитектурах. Неизменный участник самых ярких open source событий в Европе и по всему миру, популяризатор open source идей. И, кроме всего прочего, человек с отличным чувством юмора.

Петр Леменков Активный участник проекта Fedora, мейнтейнер множества пакетов и крайне интересный собеседник. Петр является одним из наиболее известных в Fedora участников российского сообщества и хорошо знаком с внутренней жизнью крупных международных open source проектов.

Константин Лепихов Координатор проекта Mozilla Россия, технический администратор. По собственному заявлению, Константин "хочет сделать Firefox самым популярным браузером в мире." И у него отлично получается двигаться в этом направлении.

Игорь Сысоев Создатель высокопроизводительного веб-сервера nginx, пользующегося популярностью во всем мире. Число сайтов, обслуживаемых nginx, превышает 56 миллионов. А сам nginx является самым популярным веб-сервером доменной зоны .ru.

Среди известных проектов его используют: Yandex, Wordpress.com, vk.com, Facebook, Rutracker.org и многие другие.

С программой Саммита можно ознакомиться на официальной странице. Секция для разработчиков начнется в 15:30 в зале "Алдан". Для участия нужна предварительная `регистрация <http://www.pcweek.ru/foss/conference/registration/>`__, будьте внимательны! Приходите! Будет интересно! :)

Кто разрабатывал ядро Linux в 2011 году?

Вышел новый отчет по компаниям, которые спонсировали разработку ядра в 2011 году. В это раз компания Microsoft попала в Top-20 компаний-разработчиков. Интересно, что хорошо известная Canonical не попала в Top-20 за 2011 год вообще. Canonical внесли изменений в ядро Linux меньше, чем Microsoft - запомните это, когда вам будут пересказывать различные слухи.

На первом месте по разработке ядра все те-же лица - Red Hat, Novell/SUSE, Intel, IBM, Oracle, Google, несколько производителей оборудования и российская компания Parallels (отличная работа, соотечественники!). Но все они по отдельности проигрывают опытному и трудоспособному разработчику - Коммьюнити. Он присутствует в отчете под названиями None, Unknown, Consultant и Academia, что означает, что разработчик ни с кем не аффилирован, неизвестно с кем, не раскрыл своего спонсора или он еще учится в институте. Суммарно, разработчики, проходящие по этим категориям, внесли почти четверть изменений, что примерно равно вкладу первой тройки корпоративных разработчиков - Red Hat, Novell/SUSE, Intel.

Но интересен еще один параметр. Каждый коммит в ядро должен пройти процедуру одобрения человека, отвечающего за участок, в который и вносится изменение. Если посмотреть на то, какие компании одобряют коммиты, то ситуация сильно меняется, и не в пользу Коммьюнити. На первом месте с 38 процентами - Red Hat (то есть больше трети коммитов потребовали одобрение от них), затем идет Novell/SUSE c 13 процентами, затем Intel c примерно 7, а потом все прочие. Коммьюнити одобрило лишь около 12 процентов коммитов. Это демонстрирует политику, приведшую Red Hat к миллиардному доходу - они всеми силами покупают ключевых разработчиков, которые разрабатывают важнейшие элементы всей экосиcтемы открытого ПО. От ядра и Glibc с GCC до GNOME и Udev с systemd - все пишется либо работниками Red Hat (и зачастую активными участниками Fedora), либо нуждается в их одобрении. Именно поэтому в Fedora всегда самое передовое ПО и самое квалифицированное коммьюнити. Присоединяйтесь!

Udev сливается с systemd

Это архивная статья

Разработчик systemd, Kay Sievers объявил о о слиянии кодовой базы systemd и udev. Для тех, кого по неизвестной нетехнической причине не устраивает systemd, сохраняется возможность собрать udev отдельно, как минимум еще некоторое время.

Новость уже активно комментируют аналитики ведущих российских сайтов о Linux.

Вышел RFRemix 16.1

Это архивная статья

Как обычно незадолго до выхода бета-версии новой Fedora, выпущена промежуточная версия RFRemix 16.1. В дистрибутив вошли ядро 3.3, KDE 4.8.1, GNOME 3.2.2, LibreOffice 3.4.5, XFCE 4.8, LXDE и прочие программы. В основном это просто обновление и исправление ошибок, выявленных с момента выхода RFRemix 16.

Как было объявлено ранее, размер установочных Live дисков теперь может быть больше 700 Мб.

Загрузка файлов:

Для загрузки доступны установочные DVD образы, Live-образы с GNOME, KDE, LXDE, XFCE и образ LiveDVD-KDE, а также файлы разницы между Fedora, RFRemix 16 и RFRemix 16.1. Загрузка возможна через зеркала, торренты и jigdo.

Через неделю ожидается выпуск Fedora 17 Beta и RFRemix 17 Beta. Релиз Fedora и RFRemix 17 намечен на 15 мая.

Обсуждение монтирования /tmp как tmpfs

Это архивная статья

В Fedora 18 принята новая "фича" - по умолчанию /tmp будет монтироваться как tmpfs, а не как папка на физическом разделе, как это сделано сейчас.

С точки зрения пользователей с большими объемами памяти, это полезное улучшение, однако не все так хорошо для пользователей с небольшими объемами ОЗУ (теперь это значит "меньше двух гигабайт"). Многие приложения интенсивно используют /tmp для хранения временных файлов, туда распаковываются архивы, производятся какие-то промежуточные операции. Это все, если примонтировать /tmp как tmpfs, будет занимать оперативную память. Но на этом претензии не заканчиваются. Участник Fedora, Richard W.M. Jones, составил краткий список проблем, с которыми придется столкнуться, что породило довольно длинную и интересную дискуссию. Также интересные претензии изложил участник Fedora Kevin Kofler (один из бывших участников FESCo) на странице обсуждения "фичи".

Проблема с хранением больших (временных) файлов в /tmp проистекает в основном из-за того, что приложения не используют стандарты FreeDesktop.org на директории для хранения временных файлов, для скачанных файлов из интернета, для документов и т.п. Об этом, и о том, как же правильно их использовать, написал статью в своем блоге Lennart Poettering.

NetBeans возвращается в Fedora?

Это архивная статья

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

Возможно, что скоро NetBeans вернется.

Основным мэйнтейнером NetBeans в Fedora был работник Sun (а впоследствии Oracle) Victor Vasilyev. К несчастью, Oracle, после приобретения обанкротившегося Sun, сократила многие OSS-проекты, что прямо или косвенно отразилось и на поддержке NetBeans в Fedora - Victor официально объявил, что прекращает быть мэйнтейнером этого и многих других Java-приложений.

Частично NetBeans занялся инженер Red Hat Omair Majid, но у него не получилось поддерживать такой сложный продукт в актуальном состоянии.

Ну, будем надеяться, что так или иначе NetBeans вернется в репозитории Fedora.

Инструкция по работе с Koji

Это архивная статья

В вики проекта закончена работа над инструкцией по работе со сборочным сервисом Koji. Этот сервис используется для автоматической сборки пакетов в Fedora. Насколько мне известно, других подобных инструкций на русском языке нет.
Спасибо, bookwar за проделанную работу!