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

Не так давно одна из компаний, которая спонсирует известный "юзер-френдли" дистрибутив, объявила, что она переходит на 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 и собирать с уже имеющимися. Так было, есть и будет - и ныне, и присно, и во веки веков.

Многие технологии, активно использующиеся в мультимедиа и 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, как отдельного пакета.

Вышел новый отчет по компаниям, которые спонсировали разработку ядра в 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 всегда самое передовое ПО и самое квалифицированное коммьюнити. Присоединяйтесь!