Russian Fedora

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

Новости архитектур

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

Консорциум Power.org сумел всех удивить совершенно странным анонсом. Оказывается, продвижение архитектуры Power в последние 10 лет шло настолько хорошо, что больше и не нужно. Ну ок, раз все хорошо, значит хорошо.

С другой стороны, OpenPower потихоньку развивается.

Недавно, IBM выложила на GitHub firmware своих OpenPower систем, что сделало их гораздо более открытыми, чем x86/x86_64 системы.

Получается, что у РФ появился еще один вариант, чтоб забросить финансировать разработку известного мифического национального микропроцессора в пользу лицензирования открытой архитектуры.

Кстати, о национальном микропроцессоре. Есть еще вариант лицензировать AArch64, уже хорошо известный в нашем коммьюнити, но с серверным ARM происходит что-то интересное. С одной стороны, Samsung и Nvidia не собираются выпускать серверные системы на базе ARM (ну, как минимум в ближайшее время). С другой стороны, ряд производителей подтвердил свои планы по выпуску серверной платформы на ARM.

Из напрямую не касающихся ARM-архитектуры событий, можно отметить новость о том, что EZchip купил Tilera, разработчика одноименной оригинальной многоядерной архитектуры. Это может сказаться позитивно на ARM-чипмейкерах просто потому, что профессионалы из Tilera начнут переходить к ARM-производителям, как предположил в своей ленте Google+ наш коллега, известный велосипедист, Jon Masters.

Тесты и логи

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

Наши участники большое значение придают тестированию. Это удивительно, но именно этим нас пытаются порой оскорбить, мол мы, это бесплатные бета-тестеры. Ну давно понятно, что в некоторых других коммьюнити ничего не тестируют, считая это позорным и глупым занятием, вываливая субоптимальный код, порой даже и неработающий толком. Мы, само собой, [STRIKEOUT:делаем все правильно] стараемся делать все правильно, хоть и не всегда получается, и тестирование, это важная и нужная часть процесса (от индивидуального тестирования, до тестовых дней).

Для тестирования нужны, как минимум, тестовый фреймворк и система журналирования. Непонимание того, что результаты куда-то надо записывать, привело к подзатухшему на текущий момент [STRIKEOUT:срачу] конструктивному обсуждению т.н. "бинарных логов", но это в целом безопасно. Гораздо хуже, что многие (и многие из нас, само собой) не используют или не умеют использовать тестовые пакеты.

Что интересно, один из мощнейших тестовых тулкитов, SystemTap, написан в основном нашими коллегами. Весной была выпущена версия 2.5, в которой добавили поддержку UEFI/SecureBoot (уже обсудили на Linux.org.ru).

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

Несмотря на наличие таких мощных средств отладки, предоставляемых пакетом SystemTap, наши коллеги нередко прибегают к самодельным, простым решениям. Благодаря им возникают забавные ситуации. Например, Andrew Phaley, инженер Red Hat, рассказал историю, как он из веревок и палок смастерил функцию-логгер для OpenJDK, которая отрабатывает за 5-20 раз быстрее, чем в случае использования стандартных средств. Ему это было нужно для измерения суб-миллисекундных интервалов внутри OpenJDK, что в свою очередь требовалось для установления причин регрессии в одной из библиотечных функций. Добился он этого благодаря отказу от потокобезопасности и благодаря использованию особенностей микропроцессора Intel в его рабочей машине. Понятно, что по сочетанию этих двух факторов, не стоит и даже думать о включении функции в OpenJDK, но его подход может быть интересен для разработчиков.

Не секрет, что некоторые разработчики неохотно и с опаской берутся за отладку библиотечных функций, и данный пример показывает, что и без SystemTap ничего особенно удивительного в пересборке базового компонента нет. Еще стоит отметить, что знание особенностей современных микропроцессоров может запросто оказаться заметным плюсом. Не забывайте ассемблер, коллеги!

Catch 22 и эффект Bumblebee в Fedora.

Участникам Fedora Community предложили использовать ПО, которое выполняет патч Бармина в стиле Bumblebee. К счастью заметили вовремя.

Самое интересное, что почти одновременно поломалась автоматическая баг-репортилка. Сообщить о баге нельзя, т.к. она не может послать сообщение.

http://s.pikabu.ru/post_img/2013/05/31/11/1370019767_1145780937.jpg

Так и живем.

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

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

Известный гентушник и дистрохоппер Greg Kroah-Hartman отмечает, что Linux уже везде, кроме вымирающего десктопа, и задается вопросом - в какую область проникнет Linux теперь? В камментах даются различные предположения. Вы, кстати, не пропустили присоединения Microsoft к проекту Linux Foundation? Вышел последний минорный апдейт RHEL 5.

Но, конечно, это не так интересно, как то, что нового в стандартных сишных библиотеках RHEL 7.

Участник Fedora ARM SIG, Rob Clark, продолжает работу над проектом freedreno. Он выпустил версию 1.2.0.

Эта версия примечательна тем, что в ней сделано все, что нужно, чтоб freedreno работал в X.org без привилегий суперпользователя.

Печальная, но предсказуемая новость - единственный доброволец, разрабатывающий Real-Time Linux, прекращает дальнейшую разработку из-за несправедливости этого мира.

С 2013 года ситуация сильно не изменилась - Red Hat ему немного подкинул денег из благотворительных побуждений, а из непосредственных компаний-пользователей результатами его труда, денег ему никто не дал.

Коллеги-аналитики уже [STRIKEOUT:сказали ненужно] обсудили на OpenNET.ru, а нам хотелось бы добавить, что ситуация (в более мелком масштабе, конечно) повторяется у нас регулярно - некие юзеры приходят к нам и требуют от нас того-то и этого-то. Если мы соглашаемся, то обычно не бывает даже никаких "здрасьте, спасибо, пожалуйста", если не соглашаемся делать ненужную лично нам работу, называют по-всякому.

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

Peter Hutterer во время работы над X.org столкнулся с тем, что из-за различий в пакетных менеджерах pkg-config устанавливается по-разному. Он написал о том, как установить *.pc файлы в разных дистрибутивах.

Появился первый коммерческий продукт, использующий Wayland - RealVNC.

Ну, конечно, Wayland уже используется в автомобилях и IVI-системах, но из коробочного ПО мы не слышали, чтоб кто-то еще уже поддерживал.

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

Яндекс получил домен высшего уровня. Будучи патриотами своей страны, искренне поздравляем!

Какие сервисы требуют перезапуска после обновления?

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

Rich W.M. Jones демонстрирует способ, которым можно установить какие сервисы нуждаются в перезапуске после обновления системы. Как вы знаете, есть популярная городская легенда, что в линуксе обновления не требуют перезагрузки (еще добавляют, что "в отличие от Windows"), так вот, это не так. Определение списка сервисов, требующих перезапуска, в общем случае, это до сих пор нерешенная задача (не в смысле "невозможно решить", а в смысле "никто пока не сделал"), но есть планы по включению этого функционала в RPM/DNF. Ждем.

Кстати, вышла альфа-версия RPM 4.12.0.

Продолжение истории с открытым OOXML.

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

Продолжается история с полуоткрытым OOXML.

Наш товарищ, Jan Wildeboer, обращает наше внимание на ее развитие - сейчас в Еврокомиссии поднимают вопрос о том, что недостаточно использовать открытое ПО *или* открытые форматы хранения данных, а необходимо, чтобы открытые форматы были реализованы в открытом ПО.

В целом это выглядит разумно. Если это предложение получит законодательную поддержку, то больше не будет монстроподобных псевдооткрытых квазистандартов наподобие OOXML.

Отрадно, что почти одновременно дружественная нам компания Collabora объявила о начале коммерческой поддержки LibreOffice. Мы очень рады за них, особенно в свете перспектив, появившихся из-за последних инициатив еврочиновников. Вполне вероятно, что они вскоре получат первые контракты на доработку открытого офисного ПО, что всем нам пойдет на пользу.

А в это время в нашей стране продолжают заниматься маниловщиной Национальных Программных Платформ.

Пользователи тачпадов, нам нужна ваша помощь!

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

Вниманию пользователей тачпадов, Peter Hutterer, разработчик X.org, просит вас о помощи.
Для исправления ряда проблем в libinput, библиотеке ввода-вывода Wayland, ему нужна информация, которую может быть получена лишь с физического устройства. И так как он не имеет доступа к большому количеству тачпадов, то один он не справится.
Вам потребуется запустить утилиту evemu-record с определенными параметрами, затем поработать на клавиатуре, повозить мышкой, но не трогать тачпад. После этого произвести еще пару действий (пожалуйста, прочтите письмо, что прислал Peter - там указаны точные инструкции), и отослать полученные данные.
1. установить пакет evemu
2. для федоры - установить конфиг для Х-ов
   # cd /etc/X11/xorg.conf.d/
   # wget http://repo.elemc.name/scripts/99-synaptics-dontgrab.conf
   перезагрузка
3. запустить:
   $ sudo evemu-record /dev/input/event4 > palm-data.txt
4. больше не пользоваться тачпадом, нормально пользоваться клавиатурой, мышкой, чем угодно, кроме тачпада
5. перед завершением работы - отменяем запись по ctrl+c, проверяем, что есть данные в файле:
   $ grep -q "^E:" palm-data.txt && echo "all clear" || echo "no data"
   если данных нет, возвращаемся к пункту 3
6. записываем данные о системе:
   $ uname -r > device-info.txt
   $ cat /sys/class/dmi/id/modalias >> device-info.txt
7. создаем архив к отправке:
   $ tar jcf palm-data.tar.bz2 palm-data.txt device-info.txt
8. выполняем нижеследующую строку и и используем ее "выхлоп", как тему e-mail:
   $ echo "PALMDATA: `cat /sys/class/dmi/id/product_version`"
9. отправляем архив, сделанный в пункте 7 с темой из пункта 8 на адрес: libinputdatacollection@gmail.com

Проблема в том, что когда юзер использует только клавиатуру и мышь, тачпад, тем не менее, может генерировать события. Их надо отсеивать программно, в драйвере. Задача выглядит простой, но она усложняется тем, что устройств слишком много, а развивают десктопный Linux не так и много людей, и в основном в рамках нашего коммьюнити и нескольких дружественных нам компаний, организаций и коммьюнити ряда других дистрибутивов. Еще одной проблемой является то, что, к сожалению, почти треть всех пользователей десктопного Linux установила другой дистрибутив, в коммьюнити которого и разработка десктопа почти не ведется (до сих пор в основном по политическим мотивам портилось то, что делают наши коллеги и товарищи), и из которого багрепорты до наших разработчиков либо вовсе не доходят, либо доходят в искаженном виде, сквозь пропатченный десктопный стек. Хотя, конечно, надо отметить, что и там есть несколько разработчиков, некоторые из которых дружат с нашими коллегами.
Поэтому Peter находится в состоянии постоянной нехватки информации, и просит вас помочь ему. К сожалению, ему требуются данные лишь с поддерживаемых версий Fedora - 19 и больше. Лучше, конечно, с 20й.
Peter предупреждает, будьте внимательны - evemu-record записывает все события с указанного устройства, и если вы ошибетесь, то вполне возможно, что запишете весь ввод с клавиатуры, включая пароли и т.п. Утилита делалась очень наспех, так что не обессудьте. Что касается списка событий с тачпада, то Peter не знает о возможностях сделать что-то неприятное пользователю, зная лишь их, так что тут все выглядит безопасно.

systemd и будущее

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

Почти с самого появления было понятно, что systemd претендует не на связку monit+sysv, но на гораздо большее. С анонсом systemd 215 (обсуждение на OpenNET.ru) это было объявлено официально, в виде доклада на FUDCON + GNOME.Asia (слайды и обсуждение на OpenNET.ru).

Теперь это официальная Linux-платформа, конструктор для создания Linux-системы. Логи, сеть, контейнеры, оборудование, пользователи - все поглощается systemd.

Конечно, есть недовольные, особенно учитывая, что при реализации планов не удалось обеспечить кое-что из запланированного. Например, так и не удалось сохранить полную работоспособность udev без systemd, но чего поделать? image0 Интересно, что udev не получится использовать без systemd из-за перехода на kdbus. Отказываться от него в апстриме systemd (или даже просто делать необязательным) не желают, т.к. плюсы от него перевешивают минусы (трех недовольных гентушников).

Уже сейчас видно, что производительность kdbus существенно выше предыдущего решения, да и другие проекты тоже рассматривают использование kdbus. Например, не так давно, D-Bus (и в частности kdbus) рассматривали в списке рассылки по flow-based programming, но, конечно, гораздо более интересным был бы перевод Binder на kdbus.

С самым первым анонсом kdbus, многие заинтересованные лица рассуждали на тему перевода Binder на kdbus или объединения проектов, очень по разному оценивая шансы на материализацию таких планов. Например, известный гентушник и дистрохоппер Greg KH полагает, что это маловероятное событие, а вот другие разработчики ядра считают иначе. John Stultz, инженер Linaro и бывший инженер IBM, который уже высказывался на Linux Plumbers Conference 2013 по поводу объединения kdbus и Binder, в своей ленте Google+ повторил, что с его точки зрения плюсы в слиянии обеих проектов перевешивают минусы, и обратил наше внимание на работу своего коллеги, Takahiro Akashi - **"Benchmarking IPCs"**, в которой измеряется скорость работы обеих систем. Выяснилось, что с умолчальными параметрами kdbus в четыре раза медленнее, чем Binder (139 микросекунд против 35), но с помощью нескольких изменений в коде kdbus удалось уменьшить задержку до 48, что, учитывая большую функциональность kdbus, вполне терпимо.

Greg KH в комментариях в ленте Google+ у Takahiro Akashi уже высказал свой скептицизм.

С его точки зрения, числа тут много не решают. Он полагает, что архитектурное различие между двумя IPC устранить будет непросто (и возможно не стоит того). А для нас особенно интересным оказалось то, что мы увидели success story использования ftrace.

К сожалению, в ядрах, доступных в Fedora, kdbus отключен (мы не включаем out-of-tree патчи), но с недавних пор появился сторонний полуофициальный репозиторий с ядрами, в которых включены тестовые фичи, и среди прочего там доступен kdbus (новость уже обсуждается на OpenNET.ru).