Russian Fedora

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

Вышел RFRemix 17-Beta

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

Сегодня выходит Fedora 17-Beta (Beefy Miracle). Одновременно мы выпускаем RFRemix 17-Beta. У нас было желание обозвать дистрибутив RFRemix 17-Beta (Pelmen') с логотипом, но пока эти мысли в доработке.

Основные новшества 17 перечислены на wiki проекта Fedora.

Дистрибутив RFRemix 17-Beta основан на development ветке Fedora 17, RPM Fusion и репозитории Russian Fedora. Из коробки доступна поддержка Adobe Flash, различных форматов мультимедиа, проприетарные драйвера Nvidia.

Основные отличия от Fedora:

  1. Наличие быстрых сценариев для установки в меню инсталлятора;
  2. Live диски имет размер больше 700 мб, что позволило положить на них больше полезных пакетов;
  3. В установщик добавлены сценарии установки различных рабочих столов (GNOME, KDE, XFCE, LXDE, Enlightment и минимальные установки GNOME и KDE;
  4. Поддержка репозиториев RPM Fusion и Russian Fedora в установщике;
  5. Добавлена возможность выбора различных клавиатурных комбинаций для смены раскладок (для русского языка). По умолчанию используется Alt+Shift;
  6. В Firstboot добавлен дополнительный экран для быстрой настройки системы (выбор между KDM и GDM, включение некоторых полезных настроек в GNOME, включение комбинации Ctrl+Alt+Backspace и др.;
  7. Система мониторинга Smolt отсылает в качестве названия дистрибутива не Fedora, а RFRemix;
  8. Пакет Freetype собран с поддержкой subpixel rendering;
  9. Словарь hunspell для русского языка содержит как русские, так и английские слова, что позволяет проверять орфографию сразу на двух языках, когда приложение этого не позволяет;
  10. В GNOME используется шрифт Cantarell с поддержкой кириллицы.

Загрузка файлов:

Для загрузки доступны установочные DVD образы, Live-образы с GNOME, KDE, LXDE, XFCE. Загрузка возможна через зеркала и торренты.

Финальная версия RFRemix 17 ожидается 22 мая.

20 апреля. МГТУ им. Баумана. Конференция «Открытые технологии в инженерном деле»

20 апреля 2012 года (т.е. уже в эту пятницу) состоится еще одно мероприятие. На этот раз более студенческое — конференция «Открытые технологии в инженерном деле». Конференция будет состоять из двух параллельных секций:

  • Секция об открытых операционных системах, программировании, о сетях и технологиях виртуализации.
  • Секция, посвященная прикладным инженерным программам, таким как: KiCAD, libreCAD, FreeCAD, Elmer, openFOAM, GNU/Octave, SciLab, Maxima, LaTeX, openSCADA

Подобное мероприятие в МГТУ проводится уже не в первый раз. В прошлом году было что-то аналогичное с весомым участием Russian Fedora.

В этом году от одного из участников проекта также ожидается доклад про технологии Red Hat в больших системах — кластерах, гридах, облаках и пр.

Сайт конференции - oskonf2012.bmstu.ru

Проход на территорию университета строго по пропускам при предъявлении паспорта => нужна предварительная регистрация. Кому интересно, не откладывайте. Регистрируйтесь прямо сейчас.

Время и место: 20 апреля 2012 года, 15:00, МГТУ им. Н.Э. Баумана, 316 ауд. (как добраться)

Расшифровка интервью с Яном. Требуется помощь!

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

В данный момент участниками проекта ведется работа по расшифровке интервью с Яном Вилдбоером, посетившим Москву на прошлой неделе. И нам требуется помощь. Если у вас есть время и знание английского, вы можете сделать хорошее дело :) Координируемся здесь.

Вы можете взять на себя кусок видео той длительности, которая вам по силам. Главное - вписывайтесь в таблицу.

Работы по исправлению регрессии в модуле ath9k в ядре 3.3.1

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

Некоторые пользователи после обновления на ядро 3.3.1 обнаружили невозможность подключиться в Wi-Fi после выхода из гибернации, если используется модуль ath9k. Проблему заметили многие, в т.ч. и в Fedora.

Сообщаем, что ошибка уже отловлена и исправлена и участник Fedora и инженер Red Hat John Linville ее уже включил в ядро (будет доступно с версии 3.3.2).

В общем, это досадный рабочий момент, ничего особенного - всяко бывает.

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

Ознакомьтесь :).

Часть функциональности Gnome, KDE и Xfce переносят в systemd

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

Продолжается победное наступление systemd на дистрибутивы. Основной мэйнтейнер Lunar Linux и сотрудник Intel, работающий над проектом Tizen, Auke Kok в своей ленте Google+ анонсировал революционное изменение, которое он уже представил на рассмотрение разработчикам systemd.

Сначала, он упомянул, что Tizen также переходит с устаревшего SysV на systemd, а затем он рассказал о его нововведении, которое создано в рамках внедрения systemd инженерами Intel совместно с инженерами Samsung - первом варианте изменений, которые предназначены для управления пользовательскими сессиями не на уровне неких демонов, встроенных в Desktop Environment (gnome-session, startxfce4 и прочих), а с помощью systemd. Он добился значительного ускорения и повышенной надежности загрузки (лучший контроль компонентов).

Какова же проблема, которую он решает? Изначально, в устаревшем SysV, не было никакой возможности запустить рабочее окружение пользователя.

Процесс загрузки выглядит так - init от суперпользователя запускает скрипты в /etc/init.d, затем запускает desktop manager (GDM, KDM, XDM или иные). Пользователь вводит пароль и логин, и desktop manager известным лишь ему образом запускает последовательность действий для запуска рабочего окружения (на этом этапе init уже никак не задействован). Таким образом, у нас есть минимум два компонента, которые запускают сервисы в системе - init и еще один на каждый Desktop Envionment, доступный на машине пользователя. Все это приводит к дублированию правил запуска для различных desktop manager, написанию неких менеджеров сессий и прочей лишней работе, результаты которой, к тому же, еще и содержат ошибки, порой трудноуловимые.

С появлением основанного на принципах философии Unix, специализированного изолированного компонента для запуска системы, который учитывает различные внешние события (он, как и полагается такому компоненту, делает только одно и делает это хорошо - следит за запуском и состоянием сервисов), оказалось можно отделить компоненты запуска рабочего окружения от Desktop Environment и сделать их полностью независимыми (и зависимыми от systemd, конечно). Auke написал первый прототип, который уже заслужил теплый отзыв от Greg Kroah-Hartman, оставленный им в его ленте Google+.

Что ж, вслед за уже почти закончившимся повальным переходом дистрибутивов на systemd, будем ожидать переходов Desktop Environment на него-же. А пользователям дистрибутивов, которые все еще по каким-то причинам не начали переход на systemd, стоило бы потормошить своих мэйнтейнеров.

"Бинарные логи" в ядре

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

Продолжаем тему о структурированном журналировании.

Jonathan Corbet пишет на LWN, что систему журналирования ядра Linux вскоре ожидают сильные изменения (к сожалению, статья за paywall). Разработчик udev и systemd Kay Sievers предложил радикально изменить поведение журналируемой подсистемы ядра.

Напомню, какова-же одна из проблем, которую решает проект Lumberjack. Изначально, из-за малого количества разработчиков и недоговоренности о стандартах, было решено, что журнал будет содержать просто текстовые строчки сообщений (например, "[system] Successfully activated service 'org.freedesktop.PolicyKit1'"). Человек в них может узнать о каких-то событиях, но роботы-то читать не умеют! Им нужна заранее заданная структура сообщений, возможно, что и не человекочитаемая (так напугавшие всех "бинарные логи"), и поэтому каждый или почти каждый сисадмин имеет свои скриптики, которые приходится постоянно переписывать, чтоб извлекать какие-то данные из журнала. Было предложено ввести структурирование журнала - отделить человеко-читаемые данные от тех, что нужны роботам. На уровне user-space это вылилось в проект Lumberjack, и, видимо, стоит ожидать скорого повсеместного внедрения "бинарных логов" в дистрибутивы.

К сожалению, в ядре до сих пор журнал ведется с помощью произвольно сформированных строк текста.

Предложение Kay Sievers содержит три пункта. Первое, это вести журнал внутри ядра не в виде некоего буфера фиксированной длины, а в виде очереди объектов. Это даже немного сэкономит память в ряде случаев и поможет предотвратить повреждение сообщений при переполнении очереди (сейчас просто перезаписывается память, занятая старыми сообщениями, что приводило к повреждению некоторых перед отправкой в логгер, работающий на уровне пользователя). Второе, это возможность присовокупить некоего KV-словаря к каждому сообщению (это и есть то самое, что будет читаться роботами - systemd, rsyslog, syslog-ng и т.п.). И, наконец, третье, это радикальное изменение поведения /dev/kmsg. Сейчас, максимум, на что оно годно, это для добавления своего сообщения к журналу событий ядра.

Sievers переработал его так, что из него можно будет читать ленту событий ядра программами типа cat и less. Поддерживается одновременное чтение событий несколькими источниками. Таким образом, это устройство становится основным источником событий ядра, которое будет удобно разбирать, и которое будет гарантированно доставлять сообщения в целости или сообщать, что некое-количество сообщений было потеряно.

В целом изменение благосклонно встречено kernel-хакерами. Даже Linus Torvalds высказался одобрительно. Стоит ожидать частичного появления этой функциональности в ядре 3.4, и окончательного - в ядре 3.5.

Грядут огромные улучшения в Nouveau.

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

Сегодня специалист Red Hat и участник Fedora Ben Skeggs анонсировал в своей ленте Google+ грядущие большие изменения в открытом видеодрайвере для видеокарт NVIDIA - nouveau. Основатель Phoronix Michael Larabel написал развернутую статью о том, какие-же изменения идут (и пообещал провести бенчмарки). Вкратце, результаты некоторых синтетических тестов улучшились вдвое (по заявлениям разработчиков), упала нагрузка на центральный процессор (также, пока не было независимой проверки), старый драйвер nvfx был заменен на новый nv30 (это касается видеокарт GeForce 5 (FX), 6 и 7).

К сожалению, все это требует одновременного использования самых новых libdrm, Mesa и nouveau, так-что я бы не ожидал это в Fedora 15 и Fedora 16. Будут-ли улучшения доступны в Fedora 17 - нельзя сказать определенно. С одной стороны, такое улучшение удовлетворяет критерию "более полная поддержка оборудования", с другой - требует нового API, что является блокирующим критерием для включения в стабильный релиз.

Итоги саммита. Подробности позже.

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

Саммит (ROSS 2012) прошел. Участники постепенно отходят :) Отчеты, видео и фотографии появятся позже. Могу только сказать, что на этом мероприятии мне повезло познакомиться с очень интересными людьми. Cреди них Jan Wildboer из Red Hat и Jesús Corrius из Document Foundation.

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

Статистика по вкладу компаний в разработку OpenStack

Не так давно одна из компаний, которая спонсирует известный "юзер-френдли" дистрибутив, объявила, что она переходит на OpenStack, как средство для развертывания своего облачного решения. Некоторые специалисты высказали предположение, что повторится типичная ситуация - эта компания никак или почти никак не участвует в развитии продуктов, которые использует (не тестирует, не исправляет ошибки, не добавляет функциональность), и с этой платформой будет точно то-же самое. И вот, теперь можно увидеть, были-ли они правы.

Специалист компании Red Hat и участник Fedora Mark McLoughlin собрал статистику, из которой следует, что инициативы Red Hat по включению OpenStack в Fedora принесли платформе гораздо больше изменений, чем Canonical. По их итогам Red Hat оказался третьим по размеру корпоративным разработчиком OpenStack. А ведь были еще и тестовые дни OpenStackсовсем недавно).

Конечно нельзя недооценивать 0.5 - 3% изменений, внесенных Canonical, и большое им спасибо и за это, но нельзя и не отметить, что это непропорционально мало по сравнению с шумом в прессе. Впрочем как и обычно.

Еще один нюанс - в отличие от Canonical, на текущий момент Red Hat не предоставляет коммерческой поддержки OpenStack в своих продуктах, хотя ходят слухи, что будет предоставлять.

10 апреля: Тестовый день KDE 4.8

Первый в истории тестовый день посвященный окружению KDE.

К тестированию особенно рекомендуются:

  • дополнительные мониторы, телевизоры;
  • wi-fi и bluetooth устройства;
  • видеокарты, виртуальные машины и т.п., неподдерживающие композитинг.