Russian Fedora

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

Content (12 страница со старыми записями)

Битва дистрибутивов в Омске. Разыскиваются участники от Fedora!

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

12 мая в Омске пройдет необычное мероприятие под названием Битва дистрибутивов. На данный момент заявлены участники от:

  • Ubuntu Linux
  • Debian Linux
  • Arch Linux
  • IPCop

От Fedora представителей пока нет, поэтому если кому-то интересно сделать рассказ о дистрибутиве самое время об этом заявить :) Так же можно связаться с организаторами через твиттер - @omsklug, #distrobattle Отдельное замечание - для участия требуется предварительная регистрация.

Новые видеодрайверы c поддержкой KMS для старых видеокарт

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

В новых ядрах больше не будет поддерживаться видеодрайверы без KMS, и поэтому Adam Jackson, участник Fedora, Russian Fedora (проверьте по его статистике на Ohloh!) и мэйнтейнер Debian, удалил их из Fedora 18 (затронет только действительно старые карты, типа S3 Trio64V+). Однако, есть проблема - некоторые действительно старые видеокарты все еще можно использовать тем, кого не очень интересуют 3D FPS игры, плюс некоторые карты все еще используются на серверном оборудовании.

Для исправления ситуации, участник Fedora, David Airlie опубликовал два патчсета - KMS драйвер для видеокарт AST и KMS драйвер для Matrox G200.

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

Прежде, чем кто-то бросится патчить иксы для поддержки старых матроксов, мы бы порекомендовали прочесть блог-пост участника Fedora, Jerome Glisse, в котором он описывает, как он потратил неделю, чтоб отловить небольшую разницу в 32-битном числе, передаваемом с видеокарты дальше.

Предложение по изменению порядка получения статуса мэйнтейнера

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

До сих пор процесс получения статуса мэйнтейнера в Fedora был довольно непрост. Мало иметь желание, нужно еще и пройти некую запутанную процедуру, представить новый пакет и найти человека, который рецензирует его и поручится за тебя ("sponsor" в принятой в проекте терминологии). Такова теория. В целом это работало, но в последние пару лет ситуация начала ухудшаться.
Давний участник Fedora, Jason L. Tibbitts III представил шокирующую статистику. В проекте Fedora участвуют более тысячи мэйнтейнеров, из которых только 102 имеют право поручаться за других (т.е. 102 человека могут принимать в проект других мэйнтейнеров), но уже 5 из них имеют статус "неактивен" или "отключен". Из этих всех, 14 человек ни разу не приняли ни одного нового мэйнтейнера, и остается ровно 88 (считая отключенных и неактивных). Из оставшихся 88, 42 не приняли никого за прошлый год, и теперь уже осталось 46 более-менее активных поручителей. Из этих-же 46 не поручились ни за кого за последние полгода - 34. Получается, что угольное ушко, в которое надо пролезть потенциальному мэйнтейнеру в проекте, очень узкое. И узкое не из-за объективных технических причин, и лишь из-за социальных проблем внутри Fedora.
Теперь становится понятно, почему мы не видим притока новых мэйнтейнеров, пропорционального интересу к Fedora среди квалифицированных разработчиков (а он очень высок) - пара десятков более-менее активных "спонсоров" просто не может обработать их заявки.
Это приводит к печальным последствиям, когда приходит человек, вывешивает заявку в Bugzilla, что он хотел бы быть мэйнтейнером, и ему нужен поручитель, поcле чего его заявка висит до полутора лет без движения и закрывается во время очередной проверки тикетов на актуальность ("true story", как говорится). Опять-же, это очень печально, когда по некоторым причинам мэйнтейнер прекращает участие в проекте, и все его пакеты становятся заброшенными, так как желающие взять их поддержку просто не могут этого сделать вовремя.
Даже без учета того, что активность "спонсоров" крайне низка, нынешняя схема не учитывает очень популярный вариант сотрудничества - человек, желающий подключиться к поддержке какого-то уже существующего пакета, вынужден включить в Fedora еще один, иначе он не получит доступ.
Например, если разработчик из upstream решит подключиться к Fedora, пожелав поддерживать в актуальном состоянии его (и только его) приложение, он не сможет этого сделать по упрощенной схеме.
С другой стороны, просто так снижать барьер или полностью его устранять - глупо. Мы - не сборище тинейджеров, форкнувших форк форка форка, и создающие очередной "легкий и простой" дистрибутив (тысячи их!), а производящие высокотехнологичный передовой продукт, многие правила которого с первого взгляда могут быть непонятны для начинающих участников. Поэтому некоторый надзор необходим.
Jason взялся проанализировать, почему в этой области ситуация настолько плоха, и почему она коренным образом отличается от других групп по интересам внутри проекта. Для начала он выделил ряд организационных проблем:
  • "Спонсоры" практически ничего не делают кроме поручительства за других (крайне редко, как видно из собранной статистики) и раз в месяц-два обсуждают новых спонсоров.
  • Нет никаких возможностей узнать, кто-же спонсор, а кто - нет (в отличие от, например, Bugzappers Team). Никакой системы координации их действий тоже нет.
  • Нет формальных критериев для спонсора. Кандидаты в спонсоры самовыдвигаются, и их принимают простым голосованием среди спонсоров (пожелавших участвовать в голосовании) по принципу "нравится - не нравится"
  • Не получается просто раздавать спонсорские права, т.к. в нынешней схеме одновременно с ними человек получает права "proven packager", что даем ему возможность вносить изменения в почти все пакеты (кроме относящихся к продуктам Mozilla - это юридическое требование Mozilla Foundation)
  • Нет никаких требований к спонсорам о том, что надо делать, чтоб не потерять этот статус. Можно его просто получить и больше ничего не делать.

Выделив основные проблемы, Jason предложил пути по нахождению их решений (пока только так). Он предлагает следующее:

  • Возложить обязанности на спонсоров, невыполнение которых приводит к потере статуса.
  • Создать средства для общения/координации спонсоров (лист рассылки, trac)
  • Разделить права "proven packager" и "sponsor" - получение одного не должно автоматически приводить к получению другого.
  • Выработать формальные права для получения статуса спонсора, чтоб снять ярлык "экзамена" или "лотереи" с процесса его получения.

Сейчас его предложение публично обсуждается, и Jason планирует представить его на рассмотрение FESCo.

На подходе Weston (композитный менеджер для Wayland)

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

Richard Hughes, инженер Red Hat и участник проектов Fedora, Gnome и RussianFedora (проверьте по статистике коммитов на Ohloh!), объявил в своей ленте Google+, что он работает над тестовым LiveCD с Wayland и Fedora 18. Сейчас проходит рецензию последний недостающий компонент - Weston. Похоже, что к Fedora 19 (а может и раньше, но в виде technology preview) мы увидим рабочий Wayland.

Можно говорить определенно, что скоро будут и тестовые дни, посвященные ему.

Сравнение мужей: Ubuntu vs Fedora

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

У Алексея Федорчука вышла новая серия заметок на ту же тему. Рекомендуем ознакомиться со взглядом со стороны. Скажем сразу - участники Fedora и Russian Fedora по ряду пунктов не согласны с автором. Тем не менее, его возражения по некоторым вопросам ценны тем, что разительно отличаются по стилистике и аргументации (в т.ч. дополнены историческими параллелями), от популярного контраргумента, состоящего из двух пунктов - "Lennart Poettering supports it" и "Lennart Poettering is an asshole".

Дискуссия вокруг systemd

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

Не прекращаются споры вокруг systemd - против него недавно высказался Mark Shuttleworth, на что тут-же среагировал в своей ленте Google+ Lennart Poettering. Следом в дискуссию вступил мэйнтейнер Fedora и один из ведущих разработчиков OLPC, Martin Langhoff. Его точка зрения заключается в том, что есть момент, о котором в общем никто и не спорит - внедрение systemd вызовет фундаментальное разделение на передовые дистрибутивы, использующие последние "фичи" Linux, и отстающих (экспериментирующих с ядрами от устаревших операционных систем, с различными Libc и пр.). Никто и не думал спорить, что cgroups, например, просто не получается задействовать в старой мешанине из BASH-скриптов без радикальных переделок всего. Опять-же нет сомнения, что Debian будет вынужден перейти на systemd, и это сильно ударит по Ubuntu, которые используют его, как upstream-проект - тут Martin и Lennart согласны.

К сожалению, "семеро одного не ждут", и если кто-то говорит, что его не интересует развитие ядра (а также, glibc, gcc, dracut, udev, GNOME, и которому вообще практически ничего не интересно, кроме неких внутрикорпоративных поделок), то непонятно, как можно ожидать, что разработчики будут подстраиваться под его нужды? Опять-же, понятно, что жертвовать Linux-специфичными вещами ради совместимости с устаревшими операционными системами - неразумно. Не для того в развитие именно Linux (а не Amiga, BSD или BeOS) вкладываются ресурсы, чтоб потом ждать, пока новые фичи реализуют догоняющие. Но так живет Open Source - люди делают то, что им надо, или за что им заплатили. Но недовольные всегда могут пойти своей дорогой и сделать что-то свое. Если, конечно, квалификации и сил у критиков хватит.

Улучшения в видеодрайвере для Intel Poulsbo/GMA500

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

Известный пользователь (и бывший мэйнтейнер) Fedora, Alan Cox в своей ленте Google+ анонсировал серьезные улучшения в драйвере для видеоадаптеров семейства Poulsbo / GMA500. Ситуация с ними была очень плохая, так как этот видеоадаптер не является собственной разработкой Intel, а лицензирован у сторонней компании, которая не разрешила Intel опубликовать исходные тексты драйвера. К сожалению, он оказался довольно распространен. Так или иначе, коммьюнити собрало вместе и написало костяк драйвера, который хоть как-то работал.

Инженеры Intel вынуждены были не прикасаться к исходникам на данном этапе, чтоб не дать повода для судебного иска о разглашении конфиденциальной информации, а смогли присоединиться лишь на финальном этапе.

Сейчас ситуация гораздо лучше, а с последним улучшение будет совсем хорошей. Alan надеется, что все последние улучшения будут доступны уже в скоро выходящей Fedora 17 - работающий suspend/resume, реализованное управление подсветкой, прямо сейчас ведутся работы по включению HDMI и исправлено множество ошибок. Ждем релиза!

Fedora ищет нового Program Manager

После того, как Robyn Bergeron повысили до лидера проекта, у нее не осталось времени на приглядывание за "фичами" проекта, за тем, чтоб все было вовремя, не нарушало принципов и правил, чтоб release engineering проходил, как запланировано. А раз так, то проекту понадобился новый менеджер. Более подробно и неформально Robyn описала фронт работ у себя в блоге, а более формально - тут. Работа интересная и увлекательная, подразумевает общение с угрюмыми и вечно злыми нердами. Если вы считаете, что подходите, то шлите резюме. Если знаете того, кто подходит и кто может согласиться - шлите ему ссылку. Ну а мы с интересом продолжим следить за интригой выбора нового менеджера.

"The spice must flow..."

Текущая ситуация с JBoss в Fedora

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

Один из разработчиков JBoss, Marek Goldmann, в своем блоге подвел итоги прошедшего недавно тестового дня JBoss Application Server в Fedora.

Почти все тесты были успешными, и удалось заметить лишь одну ошибку, которая уже исправляется - можно считать, что в целом оно работает! Парни провели просто огромную заботу - упаковали и включили в Fedora сто с лишним библиотек и приложений.

Это было очень непросто, так как традиционно Java-приложения не отличаются высоким уровнем внимания к вопросам их распространения.

Например, некоторые (не буду указывать конкретных имен) JBoss разработчики считают, что достаточно того, что они поставляют все, что нужно, в одном большом ZIP-архиве (напоминаю, что именно Java-приложения приносят наибольшее количество проблем при соблюдении правила **No Bundled Libs**).