Russian Fedora

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

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

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