Russian Fedora

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

Red Hat набирает людей!

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 появилась очень полезная фича - возможность и запускать загрузочные образы системы с помощью 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

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

Уже довольно давно начат прием фич на 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

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

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

Steampunk1man with cameraSteampunk3

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

System Message: WARNING/2 (<string>, line 16)

Title underline too short.

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

Fedora Design Team FAD

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

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

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

Новости ARM

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

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

System Message: WARNING/2 (<string>, line 13)

Block quote ends without a blank line; unexpected unindent.
А вот наш коллега, известный велосипедист, 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. Терпеть это ради юниксвэйной свободы пересобирать ядро для поддержки любого мало мальски значимого изменения ядра никто не желает. Поэтому [STRIKEOUT:уже неважно, что думают несогласные с нами, и как они это аргументируют] будет сопровождающееся овациями повсеместное внедрение ACPI и UEFI для ARM-платформы. Ну, примерно так, как это уже было с systemd.
image0
Jon Masters аргументированно и по пунктам отвечает сторонникам DeviceTree

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

OpenShift в US Navy

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

В то время, как в РФ стремятся сделать национальную ОС, чтоб запускать секретные военные программы на суверенном микропроцессоре, в США идут другим путем, по максимуму используя "гражданские" компоненты. Недавно, в блоге OpenShift, проскочила новость о новом клиенте Red Hat - PVM Inc., который успешно развернул частное облако для US Navy используя OpenShift (и не используя НацОС, секретные военные программы и суверенный микропроцессор).

image0 Облачное решение на базе OpenShift приближается к потребителю

GNU OpenMP Runtime Library теперь GNU Offloading and Multi Processing Runtime Library

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

Переименовали-таки.

После того, как в libgomp добавили поддержку offloading для Intel MIC, а на подходе появилась поддержка OpenACC 2.0 и HSA (вариант гибридной вычислительной архитектуры от AMD), то прежнее название уже не соответствовало возможностям проекта. Ну и вот.

Новости systemd

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

Lennart Poettering добавил в systemd поддержку NAT, о чем заявил в своей ленте Google+.

Была добавлена опция --port=... (например --port=tcp:1024:4096, что пробросит TCP-порт 1024 внутрь контейнера и присоединит к порту 4096) и две опции в *.network файлах, IPForwarding=yes и IPMasquerade=yes.

Таким образом, разворачивать сервисы в контейнерах стало еще легче.

Развивается и kdbus. Вы могли уже слышать, что недавно в него добавили поддержку kdbusfs для управления и получения сведений о состоянии, и вот, наконец-то Djalal Harouni объявил, что обновил unit-тесты так, чтоб все работало с kdbusfs.

Теперь kdbus полностью поддерживает kdbusfs.

В целом этот год для systemd выглядит спокойным. Все [STRIKEOUT:враги побеждены и порабощены] основные цели достигнуты, и впереди лишь техническая работа, без утомительной политики. Для пользователей Ubuntu, которым придется переходить на systemd довольно быстро, за пару релизов, на этой неделе, 15го и 16го января, планируется провести мини-спринт по окончательному переводу на systemd пары дюжин пакетов, которые содержат лишь Upstart-скрипты. Это, вероятно, будет последний шаг перед окончательным переводом Ubuntu на стандартный init-демон. Ну а для тех, кто разрабатывал на базе Ubuntu свои решения, использовавшие Upstart, уже подготовлена хаутушка для перевода на systemd.

Переход на systemd, разумеется, позволит Canonical выпускать более качественный и привлекательный для пользователей продукт. Теперь они смогут сконцентрироваться на бизнес-фичах продукта, вместо непосильной для них разработки ключевых компонентов systemd/Linux-платформы.

Понимание того, что надо фокусироваться на фичах дистрибутива, вместо абстрактных деклараций, приходит и к другим. Например, Donnie Berkholz признал, что gentoo теряет аудиторию, и ей нужны цели. Он предложил три группы людей, на нуждах которых нужно сосредоточиться - разработчики, embedded-разработчики, энтузиасты Linux.

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