Russian Fedora

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

Короткие новости

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

Sabayon окончательно перешел на systemd.

Мэйнтейнер Sabayon, Fabio Erculiani, считает, что OpenRC движется в никуда, и хотя OpenRC какое-то время еще будет поддерживаться, в будущем произойдет полный переход на systemd. Пожелаем разработчикам OpenRC побыстрее сообразить, что происходит, т.к. очень жаль, что их работа будет выброшена OSS-коммьюнити на свалку истории. Между прочим, сложилась интересная ситуация - на SysVinit остался лишь Debian, а все остальные крупные дистрибутивы перешли либо на systemd, либо на Upstart (RHEL 6, Ubuntu), либо на OpenRC (gentoo и некоторые производные), либо используют иной декларативный init-демон (Android). Так что Lennart Poettering уже добился успеха, и декларативный подход к системе инициализации побеждает императивный (SysV).

Участник Fedora, инженер Red Hat, David Miller, анонсировал выход GLIBC 2.18.

Инженер Red Hat, создатель формата Ogg и аудиокодека Vorbis, участник Fedora, Christopher “Monty” Montgomery выложил презентацию в трех частях разрабатываемого им вместе с коллегами по проекту Xiph перспективного видеокодека Daala - первая часть, вторая часть, третья часть.

Giovanni Campagna, нынешний интерн Red Hat, добился работы Weston на нескольких мониторах.

Готов для десктопа! Еще о Wayland, в Weston недавно включили базовую поддержку touch-устройств (touchscreen, touchpad).

И еще о Wayland - вышла новая версия Hawaii Shell, перспективного DE, разрабатываемого специально для Wayland с нуля (не форкая GNOME, например).

Пока выглядит аскетично, но потенциал проекта уже просматривается, и в будущем это DE может составить конкуренцию легковесным альтернативным системам, таким как LXDE и XFCE. Pier Luigi Fiorini, основной разработчик Maui и Hawaii, обычный пользователь ArchLinux, уже начал сравнивать потребление памяти с XFCE.

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

Особенно его расстроила непригодность Ubuntu для его задач, что неудивительно, т.к. у Fedora и Ubuntu принципиально разные аудитории.

Инженер Red Hat, Daniel P. Berrangé рассказывает об использовании polkit в libvirt и дальнейших планах.

В еще одном посте Daniel P. Berrangé рассказывает о том, как запустить Fedora в LXC с помощью libvirt.

И напоследок, новость совершенно не о Fedora - проект GNUstep занялся краудфандингом через Kickstarter.

Обещают добиться ссовместимости с Mac OS X 10.6, более тесной интеграции с проектом Darling. Если у кого есть желание помочь открытому проекту, то цели и суммы выглядят реалистичными.

Слайды и вдеозаписи выступлений с Flock

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

Máirín Duffy, участника GNOME Design Team, подготовила три отчета по первым трем дням конференции участников Fedora, Flock. О самой конференции мы уже мельком упомянули.

image0 Событие оказалось очень плотно заполнено интересными выступлениями, и выделить хотя-бы ключевые моменты оказалось непросто. В общем, смотрите все подряд - 9 августа, 10 авуста, 11 августа.

image1image2image3image4image5image6

Текущие недостатки архитектуры ARM

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

Rich W.M. Jones разразился гневным постом о недостатках архитектуры ARM. Он особо выделяет следующее:
  • Нет стандартного дисплея или стандартного последовательного порта для debug-консоли. На некоторых моделях последовательный порт, который можно использовать на ранних этапах, конечно, есть, но как его задействовать - никак не стандартизировано.

    Если б ARM Holdings жестко выделила бы адресное пространство для COM-порта, это было бы здорово!

  • ARM-инструкции вообще не имеют некоего минимального общего набора (например, 8086). В совокупности с первым и несколькими последующими пунктами, это делает невозможным вообще создание одного единого загрузчика системы (BIOS).

  • Стандартом де-факто для загрузки является U-Boot. Но практически никто из ARM-производителей не работает с апстримом. Для нас, для участников Fedora Project, это довольно дико, но это так - для каждого ARM-устройства есть форкнутая года два назад и порядком устаревшая копия U-Boot.

  • Сам по себе U-Boot, это еще то удовольствие. Для сборки порой требуется по-особому собранный компилятор GCC, а потом нестандартные скрипты для установки его в совершенно нестандартные носители, на нестандартные таблицы разделов. Чуть где ошибся, и получил просто черный экран (см. первый пункт).

  • U-Boot порой просто не получается заменить, т.к. под ним или над ним есть нестандартный проприетарный блоб или блобы, как это сделано на Raspberry Pi.

  • Оборудование необходимо для каждой конфигурации описать вручную, с помощью Device Tree. Чуть где ошибся, и все - черный экран (см. первый пункт). К счастью (или к несчастью), как вы уже могли от нас слышать, участники Fedora выработали рекомендации для производителей нового оборудования на ARM, и там Device Tree больше не будет.

  • Стандартных средств для подписывания ядра тоже нет. В x86_64, в общем тоже нет, но наш коллега Peter Jones уже давно разрабатывает тулкит, который скорее всего и будет объявлен стандартным средством для подписывания ядер.


Rich W.M. Jones знал обо всем этом и раньше, но сейчас он по-особенному зол, т.к. из-за влияния одного или нескольких факторов из данного списка, количество загружающихся ARM-машин у него дома уменьшилось с трех до нуля.

OpenStack Foundation намеревается присоединиться к Open Invention Network

Участник Fedora и член технического комитета OpenStack, Mark McLoughlin опубликовал очередной отчет об OpenStack Foundation Board Meeting.

Из важного надо отметить открытое обсуждение назревающей проблемы с патентными троллями, которые вскоре начнут атаковывать пользователей OpenStack прикрываясь мифической "интеллектуальной собственностью", которой, разумеется, не существует.

Было рассмотрено два возможных подхода к этой проблеме. Первый вариант, это пойти путем Google, опубликовав Patent Promise.

Второй, это пойти путем Google и присоединиться к Open Invention Network. Оба варианта имеют свои плюсы и минусы, но похоже, что OpenStack Foundation склоняется к присоединению к OIN, особенно учитывая, что совсем недавно патентное покрытие OIN было распространено и на OpenStack. Как и все вопросы, связанные с патентами, никакой публичной информации по конкретным шагам не будет, пока участники OpenStack Foundation не решат окончательно, так что ждем. Одно можно уже сказать определенно - какой бы вариант ни выбрали в OpenStack, патентная защита пользователей поставит проекта в привилегированное положение по сравнению с иными открытыми аналогами облачных систем.

Короткие новости

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

Пришло время для очередной грустной новости - если до 20 августа не найдется новых мэйнтейнеров, то из Fedora 20 исключат почти 60 пакетов, среди которых, например, GiNaC.

Как вы знаете, Fedora придерживается политики "No Bundled Libs", и любая такая библиотека (или ее часть) нами рассматривается, как ошибка, которую надо исправить. Однако исправления порой требуют довольно значительного времени. Недавно удалось распутать rsync и zlib, но на это ушло почти 4 года.

Багзилла Red Hat приближается к миллионному тикету. Мы обязательно отметим это событие, ведь оно будет значить, что в линуксе, в отличие от проприетарных операционных систем, есть как минимум миллион багов! И попробуйте с этим поспорить.

Видимо в ответ на ухудшающееся положение с продажей оборудования, IBM вместе с Google, NVIDIA, Mellanox, и Tyan анонсировали OpenPOWER, проект по лицензированию архитектуры POWER примерно так, как это делает ARM Holdings. Конечно, они б лучше сделали это десять-пятнадцать лет назад, может быть и Apple c POWER-архитектуры не ушла бы, но хоть так. В последнее время IBM пытается приманить коммьюнити, т.к. из лагеря POWER сбежали даже производители игровых приставок, и выделило своих инженеров на работы по направлению PowerLinux, которые проводятся в рамках Fedora PPC SIG, и предлагают доступ к оборудованию и помощь в исправлении ошибок, специфичных для архитектуры. Правда пока коммьюнити навстречу идет неособо охотно, т.к. зачем тратить время на исправление ошибок на редком, закрытом и дорогостоящем оборудовании, которое и пощупать-то нельзя. Мы спросили наших глубоко законспирированных агентов в IBM, осознают ли их начальники, что отсутствие killer-фичи в виде доступной материнской платы с современными характеристиками, серьезно снижает интерес коммьюнити к их архитектуре, и что они собираются с этим делать? На это наши агенты ответили, что они не могут рассказать больше, чтоб не быть раскрытыми, но в ближайшее время мы увидим современную материнскую плату на уровне топовых x86_64-систем, с полностью открытым firmware и полным комплектом документации. Ждем, но без особого энтузиазма, т.к. мы еще помним, что IBM лет 5 назад уже обещало нам вот-вот выпустить рабочую станцию на базе PPC970MP, но не осилило.

Оффлайновый тестовый день OpenStack на FLOCK

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

Как вы наверное уже слышали, традиционная американская конференция FUDCon (Fedora Users and Developers Conference) теперь будет называться Flock. Основное отличие Flock от FUDCon, это прекращение разделения на Users and Developers. Теперь конференция посвящена всем участникам Fedora, что по мнению ряда участников Fedora Project гораздо лучше передает дух нашего коммьюнити. Также резко уменьшено участие Red Hat в организации мероприятия в пользу большей вовлеченности отдельных участников и дружественных нам компаний. Среди спонсоров и организаторов мероприятия в этот раз будут такие наши друзья, как Google, Dell, Eucaliptus, Adafruit, Amazon и другие. Всем им большое спасибо за помощь! Мероприятие будет состоять из множества маленьких хакатонов (по паре часов каждый), выступлений и воркшопов (программа мероприятия). Среди них очень много интересных, но особо хотелось бы выделить предложение участника Fedora, Matthias Runge о проведении оффлайнового тестового дня по OpenStack.

К сожалению Matthias не сумеет приехать сам, но его предложение поддержал другой участник Fedora, Kashyap Chamarthy. Он и проведет тестовый день, и уже составил его план.

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

И еще пара статей об OpenStack. Если вы еще не в курсе, то в выходящем вскоре релизе (Havana, о котором мы вкратце уже упомянули) будет впервые включен Heat, компонент для оркестровки всей облачной системы. Он доступен в Fedora начиная с 18й версии, но не все заметили его появление. Участник Fedora, Zane Bitter, обращает наше внимание на это нововведение, кратко рассказывая о его предназначении и плюсах, которые он привносит конечному облачному пользователю. А в блоге компании Mirantis на Habrahabr, появился перевод статьи про другой компонент OpenStack - Ceilometer (средство мониторинга облачной системы).

Планы GNOME на Wayland

На прошедшем GUADEC были пересмотрены и скорректированы ближайшие планы GNOME по поддержке Wayland, о чем нам рассказывает в своем блоге Matthias Clasen.

Запланировано следующее:

  • К версии 3.10 будет доступно технологическое превью GNOME shell на Wayland.
  • GNOME shell будет Wayland-композитором, и будет работать на базе KMS, а не как X11 nested приложение (как сейчас по умолчанию работает Weston в Fedora).
  • Довольно значительные изменения приходится вносить в Mutter. Пока изменения для Wayland будут в отдельном бранче.
  • В дистрибутивах будет два бинарника gnome-shell - для X11 и для Weston.
  • Будет работать конфигуратор дисплея.
  • Система ввода в 3.10 не будет переведена на Wayland (в будущих релизах будет использоваться специально модифицированная IBus)
  • Возможно GDM не будет модифицирован в срок, и gnome-shell придется запускать вручную из init 3.

Очень интересно обратить внимание на то, что точно не будет работать в 3.10 (touchpad, специальные возможности, кое-какие полноэкранные функции, буфер обмена и т.п.) - с полным списком текущих регрессий можно ознакомиться на специальной странице.

В это же время проводится работа по портированию отдельных компонентов GNOME на Wayland. Недавно было анонсировано, что GNOME System Monitor 3.9.5 работает с Wayland.

Dan Walsh представил интеграцию journald и SELinux

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

Dan начал публикацию очередной серии заметок о новых security фичах Fedora 20. В первом посте он рассказал об интеграции journald и setroubleshoot.

Как вы уже в курсе, Fedora Project в очередной раз сделал выбор, в т.ч. и за тех, кто выбор делать не в состоянии из-за паралича, разбившего их коммьюнити ("we are about choice" и прочее). В качестве стандартного интерфейса для ведения системного журнала был выбран journald, и система Lumberjack, частью которой он является. Ранее, в эпоху юниксвэя, единого системного журнала не было.

Был syslog, были сообщения ядра, были отдельные логи в разных приложениях, пишущиеся в файлы, по-разному отформатированные. Чтоб связать сообщения какого-нибудь приложения, которые оно ведет в своих текстовичках, с сообщениями из syslog, или SELinux, надо было каждый раз писать небольшой скрипт на Perl и/или смеси из bash/grep/sed/awk, который затем будет периодически ломаться. Сисадмины просыпались по ночам из-за ложных срабатываний, иногда не просыпались из-за несрабатываний.Сейчас это начало исправляться в лучшую сторону.

Одна из проблемных областей, это работа с журналом SELinux. Ранее он велся в файле /var/log/audit/audit.log в виде довольно загадочных строк примерно такого вида: type=SYSCALL msg=audit(1288657341.923:641): arch=14 syscall=196 success=no exit=-13 a0=104f1755 a1=bfacfb30 a2=bfacfb30 a3=2e items=0 ppid=21254 pid=21260 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=90 comm="updatedb" exe="/usr/bin/updatedb" subj=system_u:system_r:locate_t:s0-s0:c0.c1023 key=(null) По каждому из таких сообщений создается соответствующее ему в /var/log/messages, где описывается, куда посмотреть дальше, где уже, в свою очередь, приводится команда, которую надо запустить, чтоб получить описание проблемы. Dan задумался, а почему б не автоматизировать этот процесс? Сказано - сделано (в отличие от отечественных анонимных аналитиков, максимум способных в очередной раз на форуме призвать "собирать на киллера", Dan умеет программировать).

Во-1 теперь системный журнал по умолчанию ведется в journald, а не в syslog, куда он перенаправляется с утерей части данных, для совместимости (к сожалению, в syslog смешаны концепции хранения и отображения данных, в то время, как в journald они отделены). В journald ведутся "бинарные логи" (повторимся, это только хранилище журнала, а не отображение его, которое можно получить, например, с помощью journalctl), поэтому способы анализа куда более богатые, чем простое грепанье по текстовому файлу. Во-2 начиная с Fedora 18 SELinux ведет свой журнал сразу в journald. После еще одного небольшого хака, доступного начиная с systemd 206, позволившего событиям SELinux появляться под категорией приложения, к которому они относятся, теперь есть возможность получать подробнейшую информацию об ситуации.

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

На этом Dan не остановился, и сейчас работает с мэйнтейнерами Glibc и ядра по реализации более подробных сообщений об ошибках EPERM и EACCESS.

Будет, конечно, снова неюниксвэйно.