Новость не совсем о Fedora, но о наших коллегах, которые повсюду!

Как вы слышали, изначально Valve планировала создать SteamOS на базе Ubuntu. Однако отсутствие разработчиков в Canonical привело к тому, что Valve пришлось обратиться за помощью к известному контрактору, и это стали наши друзья из Collabora, разработчики GNOME, LibreOffice, WebKit, PulseAudio и прочих десктопных компонентов Linux. Быстро оценив сложившуюся тупиковую ситуацию, они предложили простейший вариант выхода - перейти на пакетную базу Debian, пока еще не поздно. Это привело к задержке выхода SteamOS на несколько месяцев, однако позволило меньше беспокоиться о качестве пакетной базы финального продукта.

В благодарность за их работу Valve объявила, что каждый Debian Developer может получить бесплатный доступ ко всем играм Valve, прошлым и будущим.

Rainer Gerhards сделал схему всех input/output-плагинов для rsyslog:



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

Объявление для пользователей Fedora 20 и RFRemix 20:

в пакете selinux-policy-3.12.1-116.fc20 содержится баг, который проявляется при последующих обновлениях в виде примерно такого лога yum:

warning: %post(libudisks2-2.1.2-1.fc20.x86_64) scriptlet failed, exit status 127
Non-fatal POSTIN scriptlet failure in rpm package libudisks2-2.1.2-1.fc20.x86_64
  Обновление  : yum-3.4.3-130.fc20.noarch                                                       
warning: %post(yum-3.4.3-130.fc20.noarch) scriptlet failed, exit status 127
Non-fatal POSTIN scriptlet failure in rpm package yum-3.4.3-130.fc20.noarch
  Обновление  : system-config-language-1.4.0-7.fc20.noarch                                      
Для решения проблемы нужно временно перевести selinux в разрешающий режим, обновить его политики, и включить enforced-режим обратно:
# setenforce 0
# yum clean expire-cache
# yum update selinux-policy
# setenforce 1

В пакете selinux-policy-3.12.1-117.fc20 баг уже исправлен. Поэтому если вы обновились сразу на него, пропустив обновление на версию 3.12.1-116, ничего делать не нужно.

Подробности на вики-странице Common F20 Bugs

В начале 2013 года Fedora окончательно попрощалась с архитектурой SPARC, но выкинуть компьютеры ни у кого рука не поднималась. И вот, время пришло - последняя фотография SPARC-машин, на которых собиралась и работала Fedora SPARC, перед вывозом их на мусорку:

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

OpenShift официально объявил о полной поддержке CentOS. Представители OpenShift присоединятся к еще не созданной CentOS Cloud SIG и будут участвовать в CentOS Dojo. Кстати, ближайшее Dojo будет 31го января в Брюсселе, прямо перед FOSDEM, и пара наших коллег из Москвы там точно будет. Присоединяйтесь!

Участники CentOS и представители Red Hat пригласили представителей Scientific Linux к диалогу. Раньше активные участники Scientific Linux порой переходили на работу в Red Hat, как, например, Troy Dawson, о вкладе которого в Fedora мы уже писали как то, но может и тут настало время объединить проекты? Если получится, то все проекты будут жить вместе, и за бортом останутся лишь бесполезные нахлебники из известной юридической компании, один из отделов которой производит незаслуженно популярную проприетарную базу данных.

В CentOS начали вносить свой вклад сторонние разработчики! Ну, конечно, не совсем уж сторонние. Наш коллега, Andreas Thienemann, выразил интерес в сборке CentOS 7 для x86-процессоров, поддержку которых удалили из RHEL 7. Он не только выстрелил в воздух идеей, но и оформил ее в виде патчей для билдсистемы CentOS, и пересборка уже пошла. Интересно, будет ли запрос на сборку CentOS 7 для 32-битного ARM?

Lennart Poettering в рассылке dbus@lists.freedesktop.org к конце прошлого года анонсировал общую готовность kdbus и предложил начать процесс портирования приложений с библиотеки dbus1 на kdbus. Как обычно, предложение вызвало волну обсуждений - почему kbdus требует systemd? что будет с D-Bus под Windoz и Mac OS X? будет ли включена поддержка kdbus в GNOME и KDE? почему GVariant как wire-protocol формат? и т.п. Lennart постарался на все ответить, и, хотя было видно, что часть участников обсуждения из Canonical недовольны ситуацией, в целом обсуждение было конструктивно и полезно.

Из особенно полезного, инженер Samsung, Lukasz Skalski, который работает над включением kdbus в glib, сообщил, что провел серию бенчмарков kdbus и D-Bus. Из тестов складывается очень интересная картина (чем меньше, тем лучше):



Message size Elapsed time
GLIB WITH KDBUS SUPPORT
Elapsed time
GLIB + DBUS DAEMON
1000 x 4kB 1.351737 s 1.870417 s
1000 x 8kB 1.349266 s 1.857693 s
1000 x 16kB 1.383427 s 2.219304 s
1000 x 32kB 1.358608 s 2.542795 s
1000 x 64kB 1.878409 s 3.062035 s
1000 x 128kB 2.265555 s 4.043454 s
1000 x 256kB 3.112191 s 6.657750 s
1000 x 512kB 3.383699 s 11.400224 s
1000 x 1MB 4.703610 s 19.041988 s


Видно, что квадратичного роста времени отклика в зависимости от размера сообщения почти удалось избежать (с превышением 32 килобайт, что является текущим практическим лимитом для приложений, использующих D-Bus, отклик начинает медленно и почти линейно расти). Таким образом, становится возможным начинать осторожно использовать kdbus, как полноценную шину данных, скрепляя компоненты системы не пайпами, линкуя их с букетами библиотек, или как-то еще, а с помощью message passing (типизованными сообщениями) через kdbus. Это теоретически повысит надежность всей системы, и у нас постепенно появляется возможность сильнее изолировать runtime-компоненты. Практически Unix-way Reloaded!

Мнущееся у входа и никак не решающееся войти коммьюнити Debian уже полгода-год выбирает - systemd или Upstart. За systemd стоит большое коммьюнити разработчиков, техническое превосходство и инновации, которых так не хватает Debian. За Upstart стоит единственный корпоративный спонсор Debian (нанял несколько человек из Debian - другие не сделали и этого), и попытка укусить руку дающую может привести к очень тяжелым последствиям. Выбор непрост, и обсуждение затянулось далеко за три тысячи сообщений.

Когда почти все сложилось в пользу Upstart, произошли два события. Во-1 в состав комитета вошел Keith Packard, а он утилитарно и технически грамотно смотрит на вещи. Во-2 Bdale Garbee предложил вернуться в самое начало, сообщив, что он считает, что мэйнтейнеры должны поддерживать сразу несколько init-систем.


Работайте, мэйнтейнеры, солнце еще высоко!

Сложностей в поддержке нескольких init-систем Bdale не видит, как и жалоб на искусственную задержку обновления systemd в Debian, мэйнтейнеры которого вынуждены ждать, пока разработчики Upstart накопипастят еще фич из systemd, которые недавно теми и критиковались ("комбайн", "не-юниксвэй" и т.п.).

Это уже не могло понравиться никому. В конце концов, чтоб ничего не решать, для этого есть целое Debian Community, некоторые участники которого верят, что Linux Is About Choice, а Debian ctte как раз и позвали, чтоб решить хоть что-то. Инженер Canonical и разработчик systemd, Martin Pitt, возмутился и в своей ленте Google+ призвал их определяться, или туда - или сюда, "а то это ваше туда-сюда меня раздражает!".

Почти сразу не мучать кота призвали инженеры Spotify. В их коллективном письме они подчеркивают, что управляют одной из крупнейших Debian-инсталляций, которая включает одних только физических машин пять тысяч штук, не считая многих тысяч виртуальных машин с Debian, и призывают перейти на systemd целиком, т.к. он проще, и лучше приспособлен для больших сложных систем. К их письму присоединился простой сисадмин одной из полутора сотен Tier-2 вычислительных сетей для Large Hadron Collider и также призвал перейти на systemd, как однозначного технического лидера и, что также немаловажно, гораздо более открытого и свободного проекта, чем Upstart. Он припомнил Canonical их CLA, то, что они забрасывают проекты, когда теряют к ним интерес (история угасания bzr им еще не раз аукнется), и их последние движения в сторону от коммьюнити (Mir vs. Wayland). В противовес Canonical он поставил традиционную прозрачность и открытость Red Hat для коммьюнити (это интересно, но у коммьюнити нет рычагов управления Ubuntu, и решения принимает единолично Canonical).

Спектакль немного затягивается, и решение будет сложным. Можно наверное начать гадать, кого из крупных корпоративных пользователей Debian потеряет, как из-за неуверенности в перспективах проекта, управляемого настолько плохо (и так компаний, предоставляющих техподдержку у них почти нет, а будет еще меньше), так и из-за позднего решения, неважно уже какого, но уже точно с которым многие будут несогласны.

Прошли годы, и благодаря systemd, наш коллега, инженер Red Hat, Hans de Goede, добился работы X без дополнительных привилегий, и без одновременного доступа к /dev/ttyXX. Первая серия патчей уже отправлена им в список рассылки.

Идея запускать такой сложный кусок системы, как X, не под суперпользователем (и без suid-бита) не нова. С ней экспериментировал Intel в рамках уже давно забытого проекта moblin, потом Canonical попыталась реализовать, но столкнулась с рядом проблем, и отложила планы. Участники Fedora немного чувствуют вину за неудачу Canonical, т.к. мы дали им неверные подсказки, например использовать ConsoleKit, в то время, как вкладывались в systemd, переводя ConsoleKit в разряд неподдерживаемого ПО. Тем не менее, даже без ConsoleKit, оставались бы нерешенными проблемы, связанные с отсутствием системного вызова revoke, доступного, например, в OpenBSD. Разумеется, в частных случаях отдельные энтузиасты добивались работы X на самосборных системах, когда не требовалось обеспечивать безопасность единственного пользователя (см. "админ локалхоста").

И вот, наконец-то, благодаря systemd, и высокой интеграции его компонентов, мы можем в общем случае запускать X не от суперпользователя. Одна из внезапно возникших проблем, это логи X.org, которые он ведет самостоятельно, не используя даже syslog. Недавно пришедший к нам Tom Gundersen предлагает использовать syslog или Journald для ведения логов. В обсуждении в ленте Google+ участника ArchLinux, David Herrmann, инженер Linaro, Koen Kooi, предлагает использовать Journal, т.к. это сильно упростит жизнь embedded-разработчиков, которые переходят на systemd, а Aaron Seigo высказывается за общесистемное решение, т.е. за syslog или Journald.

С октября 2013 года ситуация с OpenCL в Fedora еще немного улучшилась, хотя "из коробки" пока не работает.

Участник нашего коммьюнити, Igor Gnatenko, присоединился к инициативе инженера Red Hat и разработчика oVirt, Fabian Deutsch, и предложил ряд изменений для Mesa, которые корректно включают поддержку OpenCL в библиотеке. Как минимум, можно будет запустить стандартные утилиты и получить параметры доступных OpenCL-драйверов. К сожалению, работа еще не завершена, и необходимо замерджить эти изменения в Mesa в репозиторий Fedora, и добавить еще несколько библиотек и приложений (сейчас идет работа по включению beignet).

На LWN опубликовали статистику по ядру Linux версии 3.13. Ситуация пока не меняется, и Red Hat по количеству коммитов продолжает болтаться сразу под тройкой лидеров, как в ядре 3.12, хотя и вышел на первое место по общему количеству измененных строк кода.

Дифченки обогнали Google, NVidia, Oracle и ARM по количеству патчей, а вот по количеству измененных строк не смогли войти в TOP-20. Ничего, дифченки еще нам покажут!

Но самым заметным результатом остается влияние коммьюнити - коллективный участник, скрывающийся в категориях (None), (Unknown), (Consultant), написал почти пятую часть всех патчей, что равняется примерно такой же части фактически измененных строк. Его роль крайне мала при раздаче signoffs, процессе, необходимом для включения патча в ядро, что показывает, что все ключевые разработчики уже трудоустроены. Что характерно, лидером по Signed-off-by остается Red Hat, и примерно пятая часть всех изменений была одобрена инженерами Red Hat, что позволяет компании контролировать процесс разработки ядра. Кроме Red Hat, лидерами про Signed-off-by является Intel и Linux Foundaton, после которых идут "железячники" Linaro и Samsung с Texas Instruments, после которых уже идут Google, Novell и IBM.

Страницы