Russian Fedora

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

Новости нашей инфраструктуры

В новом 2017 году мы ожидаем значительного улучшения в нашей инфраструктуре.

Для начала, мы окончательно закрываем хостинг проектов на fedorahosted.org. Там у нас, со времен, когда еще не было GitHub, крутился Trac, и хостились git-проекты с помощью gitosis. Раньше в этом был смысл, а теперь, когда появился GitHub, Launchpad, GitLab, и другие молодежные социальные сети, народ перестал посещать fedorahosted, и там засели спаммеры и хакеры. Проще выключить, чем пытаться это как-то улучшить. Окончательно fedorahosted переведут в read-only режим с марта 2017, а отключат на несколько месяцев позднее (пока не решили окончательно, когда).

Тем не менее, для проектов, которые придется хранить в нашей контролируемой инфраструктуре (ну мало ли, какие причины для этого), у нас будет вариант. Это Pagure.io, о котором мы уже говорили. Сначала мы подумывали, чтобы просто развернуть GitLab, но не осилили упаковать нужные версии сотен RoR-библиотек. Проще оказалось переписать на Python, благо среди наших коллег разработчиков на нем полно (в т.ч. и тех, кто пишут сам Python). Получилось, в общем, неплохо, хотя, конечно, до функционала GitLab не дотягивает. Но лучше, чем Trac и gitosis.

Опять о SELinux и безопасности

В который раз SELinux успешно блокировал очередную уязвимость. Вы же не настолько наивны, что его выключаете, следуя протухшим хаутушкам и советам самозваных форумных линукс-гуру? Если выключаете, то прежде, чем читать дальше, немедленно его включите обратно. В этот раз уязвимость была в Docker, в котором вообще проблем с безопасностью хватает, и если б не наши коллеги, то было бы еще больше.

Забавно, что когда наши коллеги указали, что стандартная инсталляция RHEL или Fedora, со включенным SELinux неуязвима для эксплойта, то у представителей Docker Inc., как это говорится, бомбануло. Неясно, связана ли такая враждебность с тем, что Red Hat зарабатывает на Docker больше, чем Docker Inc.? Скорее всего, нет. Просто так злятся.

Вообще, с контейнерами (т.е. просто cgroups + namespaces) надо быть осторожными. Мы уже предупреждали вас, что контейнеры не ограничивают приложения так, как бы это хотелось. Наши коллеги из CoreOS, например, в довесок к SELinux добавили специальный функционал в свой конкурирующий с Docker продукт, rkt. Они даже сделали безопасность и изоляцию основными отличительными чертами нового релиза rkt 1.14.

Мы идем своим путем, выстраивая систему безопасности с самого низа до верха. Внизу находится загрузчик с UEFI и SecureBoot, который позволяет, например, блокировать ядро от изменения из userspace. В самом ядре, в дополнение в namespaces и cgroups, наши колеги постоянно добавляют новый функционал. Недавно Daniel Mack предложил механизм фильтрации трафика в зависимости от cgroups, основанный на eBPF, что теоретически позволит очень гибко управлять трафиком контейнеров. На этом же уровне реализован SELinux.

Выше идет система инициализации системы и/или запуска контейнеров, тот же systemd, Kubernetes, rkt, Docker, fleet. Например, помимо использования SELinux, мы можем эффективно ограничивать возможности демонов благодаря функционалу systemd. Сам systemd уже нравится не только нам, но и, например, Facebook, и очень странно, что еще остались упирающиеся.

Из-за одной уязвимости, к тому же остановленной SELinux, мы, конечно, не призываем бойкотировать Docker, как другие. Просто оглянитесь вокруг - возможно вам будет удобнее управлять контейнерами используя другие механизмы (systemd, Kubernetes, rkt).

Новости RISC-V

Положительно завершается процесс добавления поддержки архитектуры RISC-V в GCC. К сожалению, процесс был сильно заторможен юристами, поэтому не факт, что успеют в срок для GCC 7. Дело в том, что разработка шла в университете Беркли, и их юристы были потив того, чтобы копирайт на работу был передан FSF. Пришлось даже переписать все с чистого листа.

Нам это все интересно, потому что сравнительно недавно наш коллега, Rich W.M. Jones, объявил о том, что он работает над поддержкой RISC-V в Fedora. Он использовал для сборки первый, заблокированный юристами, порт GCC, и с ним добился видимого прогресса - готовы образы Fedora для загрузки в эмуляторе. В качестве эмулятора можно использовать Qemu, а можно и более экзотичный RISCVEMU. В процессе пересборки Rich был вынужден вносить патчи для самых разных компонентов, таких, как RPM и systemd. Текущее состояние дел можно узнать на странице рабочей группы RISC-V в Fedora

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

PulseAudio 10.0

Вышел PulseAudio 10. Из изменений этой версии хочется отметить использование по умолчанию функционала memfd, впервые включенного в PulseAudio 9.0, и полная поддержка OpenSSL 1.1.0, с которой у нас много проблем при подготовке к Fedora 26. Это обновление OpenSSL оказалось настолько болезненное, что его уже внесли в список типичных анти-паттернов разработки. К сожалению, ситуация для криптобиблиотек довольно типичная. Они, порой, как будто специально внедряют антипаттерны разработки.

Эти и другие изменения уже обсуждаются коллегами-аналитиками на OpenNET.ru и на ЛОРе.

Canonical потеряла еще пару разработчиков

Сanonical продолжает терять квалифицированный персонал. Сначала уже известный вам разработчик systemd, Martin Pitt, объявил в своем блоге, что уходит в Red Hat. Пруфпик!

/images/martin_pitt_redhat.jpg

Сразу же за ним о своем уходе объявил и другой инженер Canonical, Daniel Holbach. Он пока не решил, где будет работать дальше.

Как стать контрибьютором в open source проект — идеи для первого патча и прочие рекомендации

По случаю перезапуска сайта хочется привести без сокращений статью, которую написал Aleksander Alekseev. Удивительно, но нас до сих пор спрашивают некоторые начинающие OSS-энтузиасты, с чего бы им начать общение с OSS-сообществом? Как раз на этот вопрос и пытается ответить Aleksander в этой статье:

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

Между прочим, интересный вопрос — а зачем это вообще кому-то может быть нужно? Для большинства людей работа над открытыми проектами — это в первую очередь возможность получить колоссальный опыт разработки, а также сделать нечто, чем будут пользоваться миллионы людей по всему миру (возможно, даже не зная об этом) ну как минимум еще ближайшие лет 10. Не стоит также списывать со счетов желание понять, как внутри устроены, скажем, операционные системы или компиляторы. Я пишу здесь об этом по той причине, что без достаточно сильной мотивации вы вряд ли найдете лишнее время для работы над каким-то там опенсорсом. Поэтому первым делом поймите для себя, что именно привлекает вас в данном конкретном проекте.

Примечание: Также вас может заинтересовать статья Как я прокачиваю владение английским языком. В мире open source, как правило, все разработчики общаются между собой на английском языке.

Далее предполагается, что вы определились с проектом, а также разобрались, как он компилируется, как прогоняются тесты, как происходит установка, а также нашли описание процесса разработки и место, куда нужно посылать патчи. Это не сложно. Примеры см в заметках Сборка LLVM-стека из исходников и чем она так интересна, PostgreSQL: сборка из исходников и настройка под Linux и Памятка по сборке ядра Linux из исходного кода. Также не повредит разобраться, как отлаживать проект. Тут все сильно зависит, помимо прочего, от используемого в проекте языка программирования, а также используемой вами ОС. Если проект написан на C или C++, то обратите внимание на мои заметки, посвященные GDB, LLDB и WinDbg. В любой непонятной ситуации не стесняйтесь обратиться за помощью в мейлинг лист или IRC-канал проекта.

Итак, с чего же можно начать:

  • Опечатки. Начните с малого. В любом достаточно крупном проекте полно опечаток, как в документации, так и в комментариях к коду. Патчу, который их исправляет, гарантированно все будут очень рады, а шансы сломать что-то таким патчем равны нулю. А значит его почти наверняка быстро примут. В процессе у вас сложится хорошее понимание, как в данном конкретном проекте нужно оформлять патчи, куда их нужно слать, и так далее.
  • Code review. Большинство программистов обожают писать код, но не очень любят читать или тестировать его. Поэтому многие проекты испытывают нехватку в ревьюверах. Будучи новичком в проекте, вы совершенно бесценны, как ревьювер! Ведь вещи, которые другим разработчикам могут казаться «очевидными», для вас таковыми не являются. При этом делать code review сравнительно просто. Как минимум, нужно проверить, что код действительно делает то, что нужно, ничего не ломает, проходит все тесты и сам покрыт тестами, не сыпет ворнингами при компиляции, хорошо документирован, оформлен в соответствии с принятым в проекте code style, не ломает обратную совместимость, и не содержит явных ошибок (например, утечки ресурсов). Что интересно, читая чужой код, вы быстро разберетесь во внутреннем устройстве проекта. Не бойтесь пропустить какие-то ошибки. Коммиттер, а также другие ревьюверы, прекрасно понимают, что вы работаете над проектом недавно, и в любом случае перепроверят за вами.
  • Исправление багов. На какие-то баги вы можете налететь сами. Особенно, если проект, над которым вы работаете — это библиотека. Но куда большие багов обычно репортят другие пользователи проекта. Проверьте багтрекер. Найдите первый понравившийся баг и попытайтесь его воспроизвести. Если не получается, постарайтесь выяснить у багрепортера детали. Может оказаться, что баг не воспроизводится или даже уже был исправлен. Закрыв тикет без какого-либо исправления, вы тоже окажете помощь проекту. Еще в поиске багов вам могут помочь санитайзеры и статические анализаторы кода.
  • Оптимизация. Обычно это халява, так как в сущности от вас требуется переписать код, чтобы он делал то же самое, только быстрее. Правда, чтобы найти настоящее «бутылочное горлышко», нужно не просто придумать синтетический бенчмарк, а иметь какую-то реальную и достаточно большую нагрузку. Само собой разумеется, выполнение оптимизации потребует от вас хорошего владения средствами профилирования кода.
  • Тесты. Печально, но факт — тесты программисты писать тоже не любят. Определите степень покрытия кода тестами, найдите непокрытые участки кода, напишите для них тесты. Удивительно, но многие программисты не понимают разницу между модульными и интеграционными тестами и никогда не слышали про property-based тесты. Если в проекте нет одного из этих видов тестов, предложите патч, который его добавляет.
  • Документация. А еще программисты часто не любят писать документацию. Проверьте, нет ли белых пятен в официальной документации или man-страницах проекта. Бывает еще так, что в документации есть несостыковки, устаревшая информация, или просто битые ссылки. Возможно, документацию можно улучшить, добавив в нее наглядных примеров.
  • Рефакторинг. В любом достаточно старом проекте есть места, которые можно переписать чуть лучше, чем они написаны сейчас. Большой файл с исходным кодом можно разбить на несколько, десяток параметров, передаваемых процедуре, можно объединить в одну структуру, и так далее. Важно, чтобы код не только решал стоящую перед ним задачу, но и был при этом читаемым!

Если позволите, хотелось бы дать еще пару советов. (1) Чем меньше ваш патч, чем больше шансов, что его примут. В частности, «заодно» подправлять отступы в не связанных с вашим патчем местах — очень плохая идея. (2) На первых порах любая прихоть коммиттера для вас — закон. Если коммиттер просит вас что-то исправить в патче, просто сделайте это, даже если ваши предпочтения не совпадают с предпочтениями коммиттера. Спор с ним попросту ни к чему не приведет. (3) Будьте предельно вежливы, используйте как можно больше слов please, thank you, и так далее. Любая грубость, троллинг, сарказм и так далее совершенно недопустимы!

Также не забывайте, что контрибьютить можно не только в виде патчей. Отвечать на вопросы в IRC и пользовательском списке рассылки, дополнять и исправлять wiki-сайт проекта, освещать новости проекта в своем блоге (можно создать рассылку ProjectName Weekly, если ее еще нет), писать обучающие статьи или, возможно, даже книги, посвященные проекту, организовать локальные юзергруппы, и так далее — все это тоже очень важные вклады в развитие проекта!

А контрибьютите ли вы в open source проекты и если да, то в какие, и каким образом?

Расписание DevConf.cz 2017

Помимо FOSDEM 2017 уже довольно давно опубликовали и расписание DevConf.cz 2017. К сожалению, в этом году организаторы были вынуждены ввести обязательную регистрацию участников, которая, по правде говоря, совсем не обременительная. В этом году мероприятие будет проходить с 27 по 29 января. Приезжайте в Брно, будем раны увидеться.

Обновление сайта

Уважаемые читатели (и писатели), добро пожаловать на наш обновленный сайт, созданный по последнему слову техники.

Главное изменение - смена движка сайта с громоздкого Drupal на легковесный статический генератор Nikola.

Что нам это дает?

  • Код сайта вместе с содержимым находится в репозитории rf-web. Репозиторий открыт, управление содержимым сайта происходит целиком и полностью через GitHub.

    Хотите опубликовать собственный материал? Присылайте pull-request.

    Хотите исправить опечатку или неточность в чужой статье? Просто присылайте pull-request.

    Не нравится оформление страницы? Всё так же присылайте pull-request.

    Хотели бы добавить несколько статических страниц? ..

    ну дальше я думаю понятно :)

  • Писать статьи можно в rst-формате в своём любимом текстовом редакторе, а можно напрямую с помощью web-интерфейса GitHub.

  • При мердже сайт автоматически обновляется благодаря настроенной автопубликации через Travis CI.

Что сделано

  • Все старые статьи экспортированы из Drupal и доступны по старым ссылкам.
  • Включена RSS-лента.
  • Для статей сайта подключена внешняя система комментариев. На данный момент это Google Plus.
  • Основные элементы оформления перенесены со старого сайта.

Недоработки

  • Система комментариев пока не протестирована, так что будем разбираться по ходу дела.
  • Много мелких недочетов в оформлении.
  • Не хватает содержательных статических страниц и FAQ.
  • При экспорте html был сконвертирован в rst-формат, в связи с чем у старых статей время от времени встречается некорректное форматирование. Такие статьи помечены как "архивные".

Как поучаствовать

Так как мы используем стандартные возможности GitHub, для участия достаточно освоиться с базовой документацией Как поучаствовать с помощью Issues и Pull Requests

Процедура собственно сборки сайта описана в README. Обратите внимание на необходимость использования Python 3.


Присоединяйтесь, вам зачтется.

Вышел RFRemix 25 - с Wayland в сеансе GNOME

Доступен для загрузки RFRemix 25, ремикс основанный на репозиториях Fedora, RPM Fusion и Russian Fedora. На этот раз RPM Fusion оправился от всех своих болячек и сделал все свои репозитории в срок. Fedora/RFRemix 25 - это первый релиз, в котором рабочий стол GNOME по-умолчанию использует Wayland. Одни говорят, что это хорошо, у других не всё так гладно, но начало положено.

Что у нас нового и старого

  • Для загрузки доступны две большие редакции RFRemix Server и Workstation (включая сетевые установки), а также Live-образы с различными рабочими столами;
  • Различные мультимедиа-кодеки, которых нет в оригинальной Fedora, а также Flash доступны из коробки;
  • Многие пакеты из репозиториев Russian Fedora доступны из приложения GNOME Software (Программы);
  • Так же у нас пересобран freetype с subpixel rendering;
  • Fontconfig содержит патчи Ubuntu для LCD мониторов (в общем сломали шрифты как всегда) и навсегда выкинули infinality, который не работал;
  • В образы Workstation (GNOME 3.22) по умолчанию для GNOME Shell (не для GTK) используется тема Korora из одноименного проекта. Также опционально добавлены темы Adapta и EvoPop для GTK и иконки EvoPop. Все отключается и включается в gnome-tweak-tool;
  • В репозитории содержится почти всевозможный набор мессенджеров: skype, viber, telegram-desktop. Также есть Chromium с pepper-flash, полный набор Opera и обычный flash-plugin.
  • Хромиум пересобран с поддержкой GTK3 и правильных кодеков;
  • Также мы обновили систему сборки. Теперь Live-образы максимально схожи с апстримовскими.

Как было сказано по умолчанию GNOME использует Wayland. Если вам такое поведение не подходит, то можно переключиться на Xorg в меню выбора сеанса.

Образы

Для загрузки доступны Live образы Workstation (GNOME), KDE (Plasma 5), LXDE, XFCE, MATE и Cinnamon. DVD и netinstall образ RFRemix Server и netinstall образ RFRemix Workstation.

Куда сходить спросить, пожаловаться

Обновление

Для обновления с предыдущих версий желательно сперва обновить текущую систему, а затем отдайте команду:

dnf --releasever=25 distro-sync --refresh --nogpgcheck
http://tigro.info/wp/wp-content/uploads/2016/11/Выделение_024.png