Russian Fedora

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

Lennart Poettering впервые увидел systemdphone, т.е. Jolla

Мы, конечно, все уже знали, что Jolla разрабатывает свой Sailfish на базе systemd и Wayland, но одно дело слышать, а другое дело - видеть и трогать руками. На фотографии Lennart Poettering впервые увидел systemdphone вживую.

https://lh3.googleusercontent.com/-01vqG5N6_kE/UuVTqQh1lHI/AAAAAAAACts/4NBDCZmSCTs/w300-h400-no/2014+-+1 https://lh4.googleusercontent.com/-x7_emYSNyiw/UuVStkAHKPI/AAAAAAAAIkY/9F8sTMB9GAU/w300-h400-no/IMG_20140126_191934.jpg

На второй фотографии вы можете заметить, что systemd в Sailfish работает в режиме user sessions, включив эту функциональность даже раньше, чем в Fedora. Кстати, коллеги-аналитики c Linux.org.ru уже тестируют телефон.

Новый wget 1.15

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

Наш коллега, инженер Red Hat и мэйнтейнер wget, Giuseppe Scrivano, в своей ленте Google+ объявил о выходе GNU wget 1.15.

Среди списка изменений особо хочется отметить добавление Perfect Forward Secrecy и ряда других улучшений, связанных с криптографией. Круги на воде от камней, брошенных Сноуденом, еще долго не разойдутся.

Сеть в systemd

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

Как вы знаете, в systemd включают управление сетью. Работу ведет недавно присоединившийся к Red Hat участник Arch Linux, Tom Gundersen. Недавно, systemd научился создавать bridge, а теперь Tom научил systemd bonding.

Если кто пропустил, то Tom написал цикл статей про свою мотивацию, текущее состояние (на момент написания) и планы по включению сетевых возможностей в systemd - постановка задачи, роль udev, libsystemd-rtnl, текущее состояние networkd (на момент написания), будущее.

Valve раздает бесплатно свои игры разработчикам Debian

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

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

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

Все плагины к rsyslog

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

Rainer Gerhards сделал схему всех input/output-плагинов для rsyslog: image0 Заметьте, сколько бэкендов для хранения бинарных логов. Rainer прекрасно знает необходимость хранения структурированной информации в бинарном виде.

Fedora 20: scriptlet failed, exit status 127

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

Объявление для пользователей 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

SPARC

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

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

CentOS начинает набирать скорость

Сразу после присоединения 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?

Первые бенчмарки kdbus

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.

Из тестов складывается очень интересная картина (чем меньше, тем лучше):

http://peter.fedorapeople.org/stuff/kdbus_benchmark.png
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 Technical Committee

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

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

http://raphaelhertzog.com/files/2011/03/bdale.jpg

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

Сложностей в поддержке нескольких 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 потеряет, как из-за неуверенности в перспективах проекта, управляемого настолько плохо (и так компаний, предоставляющих техподдержку у них почти нет, а будет еще меньше), так и из-за позднего решения, неважно уже какого, но уже точно с которым многие будут несогласны.