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

Eсли вы пользователь Firefox и вас не устраивает древний (версия 11) неразвиваемый flash-plugin от Adobe, то рекомендуем попробовать chromium-pepper-flash - флеш (версия 16) от Chrome. Для этого надо установить сам chromium-pepper-flash и freshplayerplugin из репозиториев russianfedora.
О проблемах можно писать в наш багтрекер.

Поступило интересное и неоднозначное предложение - исключить gcc, gcc-c++ и make из пакетов, устанавливаемых по умолчанию при сборке в Koji. Рациональное зерно есть - языки C и C++ медленно сдают современным молодежным языкам программирования, и приложения, написанные на этих моднейших языках, не требуют установки этих пакетов для сборки. Отказ от установки необязательных пакетов сэкономит пока еще неизмеренное время при сборках. Но есть и недостаток. Хоть они и не требуют, но и не против установки этих пакетов. А вот пакеты, написанные на C и C++ именно, что требуют присутствия этих пакетов, и для сборки пришлось бы явно указывать зависимость от gcc и gcc-c++. Это значительная работа. Пока решение не принято, и наши коллеги все еще ругаются друг на друга конструктивно обсуждают предложенное изменение.

Интересно, что это изменение сделало бы наши spec-файлы более близкими к стандартам openSUSE. Участники обеих проектов часто отмечают, что между нашими проектами слишком мало взаимодействия, и мы зачастую совершаем двойную работу. Отсутствие координации вредит обеим проектам, но, к сожалению, до значительных сдвигов в этом направлении еще далеко. Тем приятнее видеть инициативы снизу по движению в верном направлении. Например, не так давно участник openSUSE Richard Brown, в рамках работы по продвижению системы автоматического тестирования дистрибутивов, openQA, показал, что вполне возможно протестировать установку Fedora в автоматическом режиме. Автоматических тестов никогда не бывает мало, поэтому интересно, чем закончится эта инициатива.

И наконец, хорошие новости от дружественного нам проекта GDB. Инженер Red Hat и участник Fedora, Sérgio Durigan Júnior, объявил, что он настроил BuildBot для GDB. Пока крутится на его личном домене, но понятно, что как только отполируют, то перенесут куда-нибудь на официальный домен.

Christian Schaller в своем блоге объявил о массовом наборе (6-7 человек) на работу по улучшению десктопного линукса.

Вместо формального списка требований, Christian опубликовал список пожеланий к будущим сотрудникам. Чем больше пунктов подходит, тем лучше для кандидата. Список довольно обширен:



  • Able to program in C
  • Able to program in Ruby
  • Able to program in Javascript
  • Able to program in Assembly
  • Able to program in Python
  • Experience with Linux Kernel development
  • Experience with GTK+
  • Experience with Wayland
  • Experience with x.org
  • Experience with developing for PPC architecture
  • Experience with compiler optimisations
  • Experience with llvm-pipe
  • Experience with SPICE
  • Experience with developing software like Virtualbox, VNC, RDP or similar
  • Experience with building web services
  • Experience with OpenGL development
  • Experience with release engineering
  • Experience with Project Atomic
  • Experience with graphics driver enablement
  • Experience with other PC hardware enablement
  • Experience with enterprise software management tools like Satellite or ManageIQ
  • Experience with accessibility software
  • Experience with RPM packaging
  • Experience with Fedora
  • Experience with Red Hat Enterprise Linux
  • Experience with GNOME


Чтобы лучше понимать, какие задачи предстоит решать, Christian предлагает ознакомиться с десктопными фичами, которые запланированы на Fedora 22. Если вы хотите поработать над этими или схожими задачами, то напишите ему по почте cschalle(at)redhat(dot)com.

В systemd появилась очень полезная фича - возможность и запускать загрузочные образы системы с помощью systemd-nspawn. Поддержка пока ограниченная, но теперь не надо распаковывать вручную скачанные образы для виртуалки / облачной системы. Можно использовать их в systemd как есть. К сожалению, systemd не умеет пока запускать контейнер из раздела, т.е. systemd-nspawn -i /dev/sdb3 пока не работает.

Спустя пару дней были расширены и возможности systemd-import, утилиты, созданной недавно, чтобы импортировать контейнеры D*ck*r. Была добавлена возможность импортировать образы в формате qcow и сжатые с помощью XZ образы. Теперь их можно не распаковывать самостоятельно - systemd все сделает.

Кажется, что совсем недавно, в октябре 2014, был представлен первый вариант патчсета для kdbus, породивший серьезные обсуждения, и вот Greg KH предлагает третий вариант. Коллеги-аналитики уже обсуждают изменение на OpenNET.ru.

Lennart не только пишет код, но и раздает многочисленные интервью. Недавно издание Linux Voice опубликовало еще одно пространное интервью с ним. А недавно наши коллеги собрали и перевели его ответы на вопросы в рамках недавней IAmA-сессии Lennart Poettering на Reddit.

И напоследок забавное. Помните, года три назад известный хулиган и матершинник Linus Torvalds изругал разработчиков udev за то, что те решили работать синхронно и не загружать firmware до полной инициализации модуля ядра, потребовав асинхронности в загрузке firmware от разработчиков ядра? Ну, был скандал, гентушники не особо вникая в ситуацию попытались форкнуть udev, а разработчики ядра и разработчики udev требовали асинхронной работы друг от друга. Тогда дело закончилось тем, что ядро начало само загружать firmware. Так вот, та ситуация с асинхронной инициализацией модулей ядра получила развитие! Несмотря на проклятия Линуса, асинхронная загрузка драйверов оказалась интересной идеей, позволившей еще больше сократить время запуска системы, и неудивительно, что Google реализовал ее для Chrome OS. Эти патчи были недавно представлены на включение в ядро Дмитрием Тороховым. Посмотрим, чем закончится.

Наши участники делают еще один шаг в направлении общесистемных крипто-политик, работа по реализации которых начата в Fedora 21. Nikos Mavrogiannopoulos, основной разработчик криптобиблиотеки GnuTLS, создал спецификацию на работу с библиотеками OpenSSL и GnuTLS, которой должны следовать все приложения, использующие их. Расширение спецификации на nss планируется, но пока не реализовано. Остальные криптобиблиотеки, с нашей точки зрения, лучше не использовать. Если же разработчики их используют, то им стоит рассмотреть переход на одну из этих трех. В будущем останется лишь одна, но которая из них, пока непонятно.

Nikos открыл заявки в нашей багзилле на каждый пакет, который зависит от GnuTLS или OpenSSL, и прогресс уже пошел. Наши участники встретили нововведение в целом положительно.

Возвращаясь к трем основным библиотекам, мы бы рады сказать, что надо прямо сейчас переходить на %криптобиблиотека%, но это невозможно. Все три обладают несовпадающим набором функционала, к их upstream-командам есть серьезные вопросы по процессу разработки, все три обладают различными лицензиями, что не позволяет переносить функционал друг из друга. В быту проблемы вызывают все библиотеки. Но проблема еще и в том, что логика работы криптобиблиотек не всегда понятна. Криптография, это и без того непростая область, так еще и конкретные реализации усложняют процесс. Например, наш коллега, Adam Williamson, решил разобраться в деталях того, как происходит подключение дополнительные сертификатов в основных крипто-библиотеках. Сначала оказалось, что хранилище сертификатов по умолчанию в разных дистрибутивах находится в разных местах, да еще и по формату отличается (внимание, очень длинный пост), затем оказалось, что понятие "trusted" в OpenSSL гораздо сложнее, чем кажется, и не все мэйнтейнеры понимают его правильно. Последнее далось Адаму особенно тяжело.

Уже довольно давно начат прием фич на Fedora 22, и комитет FESCo уже одобрил часть из них. На настоящий момент в Fedora 22 запланированы следующие изменения:

  • Обновление BIND до версии 9.10. В этой версии произведен окончательный переход на новый формат конфигурационных файлов, что автоматически делает это изменение деструктивным.
  • Начиная с Fedora 22 в системе будет включен локальный DNS-резолвер по умолчанию. Это очередной шаг к архитектурно правильной системе работы с DNS.

    Если кто не в курсе, то юниксвэйный способ работы с DNS, это текстовичок, пригодный для чтения глазами, в котором хранится список адресов DNS-серверов и еще немного информации. За деталями обращайтесь к man resolv.conf. В общем это бы и работало, если бы не ряд проблем. Например, тот печальный факт, что при получении адресов по DHCP, установке VPN, присоединении к Wi-Fi, содержимое этого файла изменялось различными командами (и различными хуками, в самых разнообразных bash-портянках), что приводит к самым удивительным эффектам. Пытаясь обойти конкретно эту проблему, не нарушая священный юниксвэй, был предложен полурабочий вариант - resolvconf. Это еще один shell-скрипт, который подчищает изменения /etc/resolv.conf, то ли откатывая их, то ли объединяя. Разумеется, как и многие другие портянки на bash, он не работает в чуть более сложных случаях, чем думали авторы, и несчастные пользователи тратят свою жизнь в бессмысленной борьбе с этим еще одним тяжким наследием юниксвэя.

    Исправить эту и другие проблемы с текущей архитектурой реализации DNS на рабочих станциях (таймауты, если один из серверов отвалился, DNSSEC и т.п.), было предложено радикально - в /etc/resolv.conf будет содержаться единственная запись локального DNS-резолвера, который будет собирать DNS-записи, полученные по dhcp/vpn/wifi, и поддерживать DNSSEC.
  • Включение Elasticsearch, открытой поисковой системы (системы индексирования и анализа данных).
  • Традиционное обновление Boost до версии 1.58 (или 1.57). Обновление Boost, это очень деструктивное изменение, затрагивающее огромное количество пакетов, и мы обновляем его лишь с новыми версиями Fedora.
  • Обновление GHC до версии 7.8, и пересборка всего стека Haskell-приложений и библиотек новым компилятором.
  • Переход в X.org на libinput для работы с устройствами ввода. Сейчас мы используем evdev/synaptics, а они очень плохо работают с современными тачпадами на ноутбуках.
  • Замена индийских фонтов Lohit Odia и Lohit Telugu на их новую версию Lohit2.
  • Очень спорное изменение - новый консольный фонт. Несмотря на заявленную совместимость, в нем нет поддержки арабских, еврейских и кириллических символов, так что нам лучше остаться на текущем latarcyrheb-sun16. Зато в новом фонте есть полная поддержка европейских языков, греческого, и есть все смайлики.
  • Perl обновляют до версии 5.20.
  • Preupgrade Assistant, утилита, позвояющая переносить изменения конфигураций при апгрейде.
  • Перенесенная с Fedora 21 фича - Python 3 по умолчанию. Идея в том, что в дефолтной конфигурации не должно быть Python 2. Сам он, конечно, будет доступен из репозиториев.
  • Yum заменяют на DNF. Некоторые наши коллеги уже пользуются DNF, и даже вносят в него улучшения. Пока особых проблем найдено не было, хотя архитектурные отличия между ними есть.
  • Обновление Ruby до версии 2.2.
  • Вместе с Ruby будет обновлен Ruby on Rails до версии 4.2.
  • UEFI SecureBoot будет поддерживать черные списки приложений и сертификатов. Приложение, подписанное ключом, находящимся в черном списке не будет запущено, если SecureBoot будет включен.
  • Библиотека wxPython будет обновлена до последней версии 3.0.


На подходе еще пачка фич!

Начали выкладывать видеозаписи выступлений с Linux.conf.au 2015. Программа мероприятия была очень насыщенной и интересной, наших коллег было много, и остановиться на чем-то довольно непросто, так что выбирайте сами, по своему вкусу.

Steampunk1 man with camera Steampunk3


Типичные посетители этого ежегодного мероприятия

Наша команда по дизайну объявляет о Fedora Activity Day в эти выходные. Мероприятие продлится более двух дней, т.к. учитывая часовые пояса эти выходные будут долгими, а в оффлайновом виде оно будет проходить в Бостоне, США. На нем ожидается, что участники составят планы на ближайший год-два, почистят заявки в багтрекере, возможно даже поработают над обоями к Fedora 22.

Если кто не сможет заехать в Бостон, то будет можно подключиться к WebRTC-трансляции на OpenTokRTC, либо к Google Hangouts на все три дня. Присоединяйтесь!

Как вы уже знаете, наши коллеги плотно занимаются архитектурой ARM (и в частности AArch64). Например, участник Fedora ARM SIG, Rob Clark, потратил несколько лет своей жизни, чтоб к декабрю 2014 года у него появилась возможность играть в supertuxkart на ARM-платформе с видеочипом Adreno A4xx. А чего добился ты?

А вот наш коллега, известный велосипедист, Jon Masters, потратил несколько лет на стандартизацию AArch64-архитектуры, и теперь современная ARM-платформа не требует специального ядра для каждой конкретной материнской платы. Предсказуемо, но унификация была принята в штыки embedded-разработчиками, которые трудоустроены в хардверных ARM-компаниях, традиционно придерживавшихся стратегии максимально быстрого вывода продукта на рынок. Чтобы наконец убедить скептиков Grant Likely из Linaro постарался написать уже наверное стотыщпятисотую статью, почему надо взять ACPI, и отказаться от DeviceTree. Вкратце, ACPI выгодно для создателей операционных систем, в частности дистрибутивов Linux, т.к. его модель поддержки совершенно отличается от DeviceTree, который требует собирать ядро для каждой конфигурации. Действительно, DeviceTree вполне достаточно для сборки системы для телефона, которая больше не требует апгрейдов (маркетологи требуют сделать так, чтоб пользователь не апгрейдил телефон, а каждый раз покупал новый), и предназначена, чтоб запускать однопоточную джава-машину и играть там в птиц и свиней и веселую ферму. Но чтоб собирать дистрибутив, который бы работал без изменений на всех текущих и будущих системах, этого мало. Ядро там пересобирать при замене RAID-контроллера или сетевухи никто не будет, и удивительно, что embedded-разработчики всерьез это предлагают.

Вообще, вырисовывается интересная картина. ACPI, для не-embedded программиста наверное проще всего представить в виде некоей runtime-сущности, например, шины данных и/или протокола управления, а DeviceTree, это строго compile-time опция. Если так, то становится понятна деформация восприятия ACPI людьми, привыкшими "пересобирать мир". Интересно, что со статичностью DeviceTree его сторонники борются уже давно (например, мы как-то уже слышали про странную концепцию оверлеев).

К сожалению, и в этот раз статья Гранта убедила лишь тех, кто и так убежден, и споры начались уже в ленте Google+ автора. Более-менее развернутое контр-мнение, без детских вскриков про злой Microsoft и драгоценную юниксвэйную свободу выбора из десяти вариантов, привел Pavel Machek. Он обеспокоен следующим:

  • ACPI требует интерпретатор в ядре (см. чуть выше - ACPI, это runtime-сервис, в то время, как DeviceTree, это compile-time фича).
  • Больший объем байткода для поддержки драйверов в ACPI (и, как полагает Pavel, более хрупкий) вместо нескольких строчек в описании DeviceTree.
  • ARM-серверы явно начинают архитектурно отличаться от embedded-ARM.


К дискуссии подключился и Jon Masters. В своей ленте Google+ он согласился с большей усложненностью ACPI, но еще раз привел три аргумента в его пользу - это стандарт, это стандарт, и это стандарт. Если не ACPI, то разработчикам дистрибутивов общего пользования придется продираться сквозь Cute Embedded Nonsense Hacks, более-менее общий перечень которых, как вы могли слышать, однажды составил Rich WM Jones. Терпеть это ради юниксвэйной свободы пересобирать ядро для поддержки любого мало мальски значимого изменения ядра никто не желает. Поэтому уже неважно, что думают несогласные с нами, и как они это аргументируют будет сопровождающееся овациями повсеместное внедрение ACPI и UEFI для ARM-платформы. Ну, примерно так, как это уже было с systemd.


Jon Masters аргументированно и по пунктам отвечает сторонникам DeviceTree


Пока в коробке мечутся, забавно сталкиваясь друг с другом, напуганные сторонники DeviceTree, наши коллеги, посматривая на них слегка свысока, но дружелюбно, продолжают работу. Marcin Juszkiewicz, недавно отмечавший двухлетнюю годовщину своей занятости над AArch64, сообщает, что запустил X11 на физическом железе AArch64.

Страницы