Сформирована программа конференции systemd.conf 2016. Среди выступающих как представители крупных корпоративных пользователей systemd (Bosch, n:stack / StackHut, NixOS, Facebook, например), так и компаний-разработчиков (например, Red Hat, Endocode, ProFUSION, Pengutronix, CoreOS, Canonical, Kinvolk). Интересно, остались ли те, кто считает, что systemd "ненужно" и "закопать"?

После выявления проблем с производительностью и после включения и поспешного отключения kdbus в Fedora Rawhide, разработка была свернута в пользу совершенно нового проекта - bus1. И вот, наконец-то, анонсировали его первую публичную версию. Разработчики резко упростили реализуемый функционал перепозиционировав проект, как n-to-n шина сообщений с поддержкой multicast и unicast и с системой безопасности на базе capabilities. Это было бы аналогом Binder из Android, если бы тот умел multicast. Из-за поддержки multicast пришлось добавить функционал неизменности порядка сообщений, т.е. если сторона (или стороны) отправила пакет A, а затем B, то независимо от того, unicast это или multicast, адресат получит сначала A, затем B.

Neil Brown уже написал статью на LWN, под которой началось интересное обсуждение. Учитывая фиаско с kdbus, наверное не стоит ожидать быстрого включения функционала bus1 в дистрибутивы, но пока мы сохраняем осторожный оптимизм.

Ну и из смешного - в systemd включили systemd-mount. Напоминаем:

Если кто не в курсе, то идеи, что в systemd надо включить управление сетью, wpa_supplicant, минимальный shell, минимальный текстовый редактор (для работы с конфигами), монтирование, управление логинами, и пр. высказываются регулярно. Люди вокруг тут-же начинают шутить про emacs, а вот Lennart сразу-же задумывается и даже забывает про бокал пива в руке.

Довольно горячее обсуждение вызвала публикация о переосмыслении разделения процессорных архитектур, для которых собираются пакеты в Koji на первичные и вторичные. Сейчас разделение осуществляется на уровне сборки - Koji для secondary arch физически отделен. Предлагается объeдинить все работоспособные сборщики в одну точку входа. Сделать это предлагается постепенно - с Fedora 26 к имеющимся сборщикам для i686, x86_64, armv7hl добавится сборщик для aarch64, а с Fedora 27 добавятся сборщики для архитектур Power64 и s390.

Не все мэйнтейнеры обрадовались и поддержали предложение. Многие имеют негативные впечатления от тормозного сборщика для armv7hl (давным давно кто-то померял результаты сборки на физическом оборудовании для armv7hl, и в Qemu, запущенном на мощном Intel-процессоре, и оказалось, что в эмуляторе получается быстрее), и опасаются, что добавление новых сборщиков для систем, которыми пользуются десятки человек, сильно затруднит процесс сборки. Другие недовольны тем, что если предложение примут, то ошибки сборки на непопулярных архитектурах будут блокировать сборку и на популярных. Пока идет обсуждение, но скорее всего примут.

Масла в огонь подлил наш коллега Rich W.M. Jones, который с радостью объявил, что вовсю идет процесс пересборки Fedora для новой процессорной архитектуры - RISC-V. Для архитектуры, считай, не существует физического оборудования (надо покупать FPGA и заливать туда прошивку проприетарными утилитами, работающими только под Windoz, либо использовать Qemu), и его неосторожное высказывание, что он надеется сделать ее основной архитектурой сборки еще больше разозлило тех, кто не желает терпеть проблемы от непопулярных архитектур. Для RISC-V уже есть поддержка в ядре Linux, в GCC, и в Glibc, но в остальном еще работы много. Например, только начали добавлять поддержку RISC-V в RPM. Так что опасения народа довольно понятны.

Мы будем следить за развитием событий.

Сформирована программа конференции LibreOffice Conference 2016, которая состоится с 7 по 9 сентября 2016 года в Брно. Приезжайте, обсудим текущее состояние и тенденции развития офисного пакета и его аналогов.




Поздравляем коллег, работающих по соседству! Наконец-то им можно официально ходить в офисе в шортах и футболке.

Последние несколько лет мэйнтейнером gettext является наш коллега, инженер Red Hat и участник Fedora Project, Daiki Ueno. За это время в gettext были внесены важные улучшения, благодаря которым нет никакой нужды использовать конкурирующее решение - intltool, разрабатывающееся в Launchpad с помощью bzr. Наш коллега, Matthias Clasen, в своем блоге постарался рассказать о преимуществах gettext. Вкратце, это большое количество понимаемых форматов (*.desktop, файлы Gtkbuilder, *.appdata.xml, *.metainfo.xml), включение и использование переведенных строк, и удобство подключения новых XML-форматов к gettext.

Peter Hutterer объявил, что libinput окончательно завершен. У него закончился TODO-список. Эта библиотека будет основным источником ввода для Wayland, поэтому это очень важно. Fedora перешла на libinput, как основной драйвер для X11 начиная с Fedora 22 - таким образом будет достигнут бесшовный переход на Wayland. Недавно, кстати, выпустили Wayland Protocols 1.5 - набор дополнительных протоколов для Wayland, и среди изменений есть относящиеся к touchpad. Немного опасаемся за будущее Wayland. В XMPP идея о базовом функционале и дополнительных функциях, реализуемых в виде необязательных к следованию им XEP, привела к тому, что гарантированно работали только базовые функции, и от протокола массово начали отказываться большие вендоры в пользу самописных, более функциональных решений.

Постепенно набирает скорость Vulkan. Наш коллега, инженер Red Hat и участник Fedora и Debian, David Airlie, предложил первый вариант Vulkan-драйвера для некоторых видеокарт AMD.

Новости о systemd больше не пугают революционностью. Недавно systemd дорос до версии 231. Основная работа, судя по ChangeLog, идет в направлении контейнеров и systemd-networkd. Интересно, что и systemd, и wayland стали настолько хороши, что GNOME в Fedora 24 теперь использует их практически незаметно для пользователя (обратите внимание на строку 259, где располагается процесс с PID 2147). А ведь нам уже говорили, что systemd --user планировали переработать.

Наши друзья из Parallels / OpenVZ наконец-то выпустили седьмую версию своего флагманского продукта. В этой версии, что особенно примечательно, было принято решение использовать KVM вместо самописного проприетарного гипервизора. Из других фич - использование CRIU для живой миграции контейнеров, еще меньшая разница между ядрами OpenVZ и RHEL, и постепенный отказ от утилиты vzctl в пользу virsh или аналогичных решений. И особенно хочется отметить последовательную реализацию плана по открытию своих технологий и увеличению прозрачности процесса. Вы знали, что у OpenVZ есть аккаунт на GitHub?

Решения, разработанные в Parallels, разбираются и другими вендорами, например Red Hat, где CRIU доступен как "technology preview" начиная с RHEL 7.2. В RHEL версия уже старовата, но попробовать можно. К сожалению не всегда к инженерам Parallels прислушиваются внимательно. Например, разработчики Parallels нашли ошибку в ядре года три назад, но тогда никто особо не заинтересовался. А вот недавно, та ошибка внезапно привлекла всеобщее внимание, т.к. с помощью Docker, который как некоторые ошибочно считают мегабезопасен, ее можно использовать на некоторых хостингах контейнеров. Сразу бы так.

Один из наших коллег был вынужден использовать вот такой патч:

--14,-14,-14,-14,-14,-14,-14,-14, -14,-14,-14,-14,-14,-14,-14,-14,
--14,-14,-14,-14,-14,-14,-14,-14, -14,-14,-14,-14,-14,-14,-14,-14,
+(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14, (uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,
+(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14, (uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,


Не все так однозначно!

Ситуация с языком Rust сдвинулась с мертвой точки. Совсем недавно Rust официально одобрили для включения в Fedora. Как раз успеем - наши коллеги уже используют язык для системного ПО, и отладка приложений на Rust уже доступна в GBD. Включение Rust и сопутствующей сборочной инфраструктуры, пакета Cargo, объявлено фичей Fedora 25.

Firefox с версии 48 будет использовать компоненты, написанные на Rust, и разработчики Mozilla Foundation всячески призывают следовать их примеру. Так что инициатива нашего коллеги, Andy Grover, по использованию Rust в системном ПО тоже получила поддержку с их стороны. Недавно Andy выступил на ежемесячном митапе по Rust, проводимом MoFo. Тема его выступления была - "Froyo: Using Rust to get fancy with storage". К сожалению, доступно только видео на Archive.org:



Раз уж заговорили о Rust, то обратите внимание на это спорное предложение. Will Crichton, бывший интерн Palantir Technologies и Jane Street Capital, предлагает при разработке DSL и просто новых языков программирования выбирать не LLVM, а Rust в качестве целевой платформы. К 2035 году в РФ планируют разработать суверенный национальный язык программирования, безопасный к взлому и уводу аккаунта во Вконтакте, так что самое время начать обсуждение его архитектуры.

Потихоньку идет процесс перевода операционок от Google на современные компоненты. Несмотря на то, что Chrome OS и Android не будут сливаться в одну систему (т.е. будут, но путем переноса фич туда-сюда, а обои будут разные), и та, и эта системы пока технологически отстают от дистрибутивов линукса. Например, SELinux в Android включили лишь в 2012 году, что гораздо позже Fedora / RHEL (ну, кстати, в Ubuntu его до сих пор нет, что сильно подрывает и без того плохую ситуацию с безопасностью этого дистрибутива). PulseAudio и Wayland были доступны на Android в качестве очень очень экспериментальной сборки от стороннего разработчика. Но самая плохая ситуация была с системой инициализации. В Chrome OS до сих пор используется Upstart, а в Android самописная система инициализации - init. К счастью, благодаря тому, что Chrome OS основана на Gentoo, сменить init-систему на systemd не так и сложно, что продемонстрировали разработчики CoreOS, заменившие Upstart на systemd. Тем не менее, пока Chrome OS официально использовал лишь устаревший и малофункциональный Upstart.

Неожиданно выяснилось, что инженеры Intel уже несколько месяцев работают над возможностью использовать стандартное дерево Chrome OS с systemd. Пока непонятно, насколько полно поддерживается systemd в Chrome OS, но новость позитивная.

Страницы