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

На LWN опубликовали рекап выступления Pavel Emelyanov из Parallels на "2013 Kernel Summit", - "Checkpoint/restart in user space". Сначала Павел рассказал об истории CRIU. Затем, он попросил разработчиков новых фич ядра всегда добавлять механизм получения текущего состояния (приведя пример с таймерами, которые можно создавать и уничтожать, но нельзя получить текущее состояние, почему ему пришлось дорабатывать эту функциональность), и попросил не увлекаться глобальными идентификаторами в ядре, предпочитая им локальные (привязанные к процессам). Павел также рассказал о разрабатываемой функциональности CRIU - checkpoint/restore всех процессов системы, перезапуск ядра с сохранением памяти нетронутой, и возвращение процессов, используя "старую" память. Это должно работать очень быстро. `Andrew Morton <>`__ спросил, а можно ли написать приложение, которое принципиально невозможно зачекпойнтить/отресторить? Павел ответил, что пока да, например Unix-сокеты вызывают проблемы, но он работает над этим - разработчики systemd хотят использовать эту функциональность.

CRIU уже вовсю используется, между прочим. Разработчикам сообщили, что CRIU сумел сохранить и впоследствии восстановить 48-гигабайтное приложение.

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

Уже известный вам наш коллега, участник Fedora и член технического комитета OpenStack, Mark McLoughlin изложил свои соображения на тему, OpenStack и его базовые компоненты.

Проблема, давно вставшая перед ведущими игроками, вкладывающимися в OpenStack, это то, какие компоненты вообще могут содержать в названии торговую марку OpenStack? Эта тема уже давно обсуждается на самом высшем уровне иерархии OpenStack Foundation (например, Rob Hirschfeld, участник совета директоров, написал серию статей по вопросу), и ее актуальность вероятно уже достигла высшей точки. Дело в том, что OpenStack, это платформа, на которой строят свои решения самые разные заинтересованные стороны. И растущая популярность платформы приводит к тому, что разные компоненты в рамках разных предложений могут быть изменены на аналоги, проапгрейжены или даунгрейжены на другие версии, к ним могут быть добавлены еще какие-то компоненты, в них могут быть внесены иные изменения, продиктованные бизнес-процессами. Будет ли то, что получится, все еще OpenStack или нет? Или даже так - сможет ли пользователь такого измененного решения смигрировать на решение другого вендора? Rob в августе этого года написал список из десяти предложений, чтобы определить то, какие компоненты, могут содержать в названии "OpenStack".

Mark зацепился за предложение, что "все компоненты из Core должны проходить все базовые тесты". Речь идет о минимальном наборе модулей, с которыми бы все базовые тесты отрабатывали успешно.

Mark опасается, что определение для сертифицированного OpenStack Cloud провайдера (если некий референсный набор внешних тестов отработает на инфраструктуре, то можно официально выдавать такому провайдеру подтверждение / сертификат соответствия) без должного обдумывания, механически переносится в определение области ключевых компонентов системы. Он считает, что тесты определяют лишь пригодность API для ряда типичных use cases, а за API могут быть совершенно иные компоненты, с разными версиями и даже реализациями. Это позволяет взглянуть на проблему с совершенно новой стороны - а зачем регламентировать набор ключевых компонентов вообще (OpenStack Core)? Почему бы не заняться вопросом определения границ OpenStack Compatible Cloud? Mark сомневается, что защита торговой марки тут поможет - пользователям нужна совместимость на уровне API больше, чем соответствие реализации покомпонентно, и для достижения совместимости по API облачные провайдеры точно будут менять различные компоненты, даже те, что сейчас кое-как подводят под определение "OpenStack Core". Mark замечает, что провайдерам будет выгоднее заявлять о полной совместимости с OpenStack, чем о заявлении об использовании OpenStack Core, и он считает, что дальнейшее обсуждение списка ключевых компонент будет тупиковым путем. Он предлагает немедленно начать обсуждение определение "OpenStack Compatible Cloud", т.е. какой API должны предоставлять провайдеры, и обсудить, какие шаги предпринять, чтоб провайдеры, которые хотят быть совместимыми, использовали компоненты OpenStack, а не аналоги.

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

Работает он на базе Fedora, разумеется:

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

В этот раз свое спасибо сказал еще один embedded-разработчик, инженер компании Axis Communications. Они сильно упростили себе разработку и поддержку решений, используя systemd. Чтоб он лучше подходил под их нужды, они общаются с разработчиками, обсуждая и сравнивая различные подходы и отправляя багрепорты. Вот так вот! Это и называется конструктивный подход.

До сих пор этот стандарт поддерживали лишь gummiboot и systemd (и существует патч для grub2).

Надвигающуюся потенциальную проблему хорошо озвучил в своей ленте Google+ разработчик Coreboot, Patrick Georgi - UEFI Forum может запросто спрятать спецификации за некими юридическими соглашениями, что будет препятствием для разработчиков, особенно разработчиков открытого оборудования.

Среди фич - долгожданная отмена транзакций (yum history undo) и ограничение по количеству устанавливаемых в параллель пакетов (kernel, например).

# systemd-run /usr/bin/cpuburn

# systemd-run -H login.example.com /usr/bin/cpuburn

#  systemd-run -M mycontainer /usr/bin/cpuburn

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

Подведены итоги недавно прошедших тестовых дней по графической подсистеме (к сожалению, был отменен тестовый день по Wayland). В тестах участвовало 29 человек, и они нашли за три дня 18 багов, что очень хорошо! Для Intel-драйверов было 187 тест-кейсов, для Radeon - 153, а для Nouveau пока есть лишь 95 тестов. Для тестов 3D надо было играть в игры, так что тестирование протекало весело.

Следующий тестовый день, 5 ноября, будет по печати (CUPS и букет сопутствующих приложений), и инженер Red Hat, Tim Waugh официально приглашает всех поучаствовать.

Приходите, если у вас порой есть необходимость печатать.

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

Пройти мимо этой новости не получится, т.к. она косвенно скажется и на нас тоже. Появилась новая реализация кодека H.264, от компании Cisco, одного из лицензиаров патентов на идеи, чья т.н. "интеллектуальная собственность" (которой, разумеется, не существует), входит в патентный пул печально известного вымогателя, MPEG-LA.

Вскоре в IETF будет обсуждение по поводу стандартов на видеосвязь в интернете, и пока большая часть имеющих право голоса склонялась к открытому VP8, в т.ч. и потому, что H.264 невозможно использовать без уплаты дани рэкетиру. Юристы Cisco придумали, как обойти проблему - если вы выпускаете продукт, который скачивает предсобранные блобы с сайта Cisco, то платить вы не обязаны. Если же вы предварительно скачаете блобы (или соберете из исходников), то платить придется. Такова юридическая логика.

Письмо в IETF уже откомментировал создатель формата Ogg и аудиокодека Vorbis, участник Fedora, Christopher “Monty” Montgomery. Он пишет, что пора признать суровую правду - мы, OSS-коммьюнити, проиграли эту битву войны, и юзеры будут платить (через включение стоимости лицензий в товары, например) рэкетиру. Стартовые условия были неравны. Но война с цапками от мультимедиа еще не закончена, и впереди у нас есть шанс переломить ситуацию, т.к. вот вот начнется битва за видеокодеки нового поколения, где у нас позиции лучше, чем у вымогателей. Открытых решений сразу два - Daala от Xiph (на последней конференции по GStreamer в Эдинбурге, Gregory Maxwell рассказывал об истории его разработки, и на LWN уже есть рекап его выступления) и VP9 от Google, и они оба немного обгоняют по готовности H.265 / HEVC, за которым стоит все тот же бандит, MPEG LA.

Ну и ожидаемое. Mozilla Foundation согласилась использовать кодек от Cisco в будущих версиях Firefox.

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

Jan разделил пользователей RPM на три группы - существующие пользователи, у которых ничего не должно в результате изменений поломаться, разработчики, постоянно ставящие что-то из исходников, в обход RPM, и devops/админы, использующие Chef/Puppet для синхронизации машин, и не использующих RPM. Ну и как всегда, у любого сколь нибудь развитого языка программирования есть свой способ собирать дополнения для этого языка, ничего не знающий о пакетах. Отдельно он отмечает неготовость для десктопа существующих графических интерфейсов, хотя благодаря работе Richard Hughes процесс идет.

Сейчас Jan предлагает следующий план исправления сложившейся ситуации:

Ближайший год / в процессе.

• Дельты метаданных для Yum/DNF вместо постоянного выкачивания десятков мегабайт загзипованных XML.
• Переход на Python3 в DNF.
• Новый бинарный формат для RPM. Пока, любые попытки написать свою реализацию парсера пакета сопровождаются зубовным скрежетом и криками "быдлокод".
• Интерфейс для написания плугинов для RPM.

1-2 года.

• Стабилизация DNF и замена им Yum.
• Улучшенная поддержка SELinux.
• Сложные "вычисляемые" зависимости. Это совершенно новая фича. Суть в том, что зависимости будут не только "зашитые", но и вычисляемые в момент установки/удаления других пакетов. Они будут записываться в базу данных Yum и будут переопределять существующие, либо добавляться к ним. Короче говоря, это второе появление "Recommends", вычисляемых, а не записываемых на этапе сборки.
• Новый бинарный формат для RPMDB. Он должен быть расширяем, причем с заделом на будущее. Например, NoSQL-база для JSON-записей?
• Новая база для yumdb. На самом деле, пока сложно сказать, что будет в ней, а что в RPMDB, но уже ясно, что ее тоже придется изменять и расширять.
• Дальнейшее упрощение формата spec-файлов.
• Обработка пакетов, удаленных из репозиториев.

2-5 лет. Высокий приоритет.

• Управление репозиториями из командной строки. Хочется сделать так же просто, как и подключение PPA в Ubuntu. Опять-же, RPM/Yum/DNF должен не перекачивать метаданные в случае переименования репозитория, как это сейчас происходит.

• rpmbuild должен выходить с ошибкой в случае не-UTF8 spec-файлов.

  Выкиньте уже ваши KOI8-R файлы, пожалуйста.

• Быстрое создание RPM-файла (cabal2spec, gem2spec, и т.п. + подсказки по BuildRequires + больше автогенераторов Requires).

• Быстрое создание Software Collections. Например для Python или Ruby другой версии.

2-5 лет. Средний приоритет.

• Улучшение журналирования операций (перенос из Yum в rpm).
• Уменьшение количества блокирующих операций.
• Интеграция с облачными системами, такими, как OpenShift.
• Автоматическое подключение внешних RPM-баз. Например, вы подключаете NFS-раздел, и RPM находит установленные там пакеты и управляет ими (например, перевычисляет вычислимые зависимости).

2-5 лет. Низкий приоритет.

• Потокобезопасность RPM. Не смейтесь, пожалуйста, нам самим грустно.

  Сейчас мы просто не позволяем запускать вторую копию Yum/DNF в параллель - очень удобный и простой фикс для достижения threadsafe.

• Интеграция с состоянием демонов. Не только перезапуск, но и перезапуск по какому-то системному событию (обновление других демонов, например).

• Улучшение верификации. Например, не только сообщение об изменении файла, но и diff изменения, если речь идет об изменении файлов конфигураций.

• Автообновление конфигурационных файлов. Сейчас, т.к. изменения не вычисляются, то если администратор изменил конфиг, установленный в пакете, а обновленный пакет содержит обновленный-же конфиг, то останется старый файл, а новый будет установлен рядом, как *.rpmnew.

  Хотелось бы применить изменения к новому и установить его.

Далекое светлое будущее. Низкий приоритет.

• Полностью модульный RPM, создающий пакеты не только из SPEC-файлов, и на выходе выдающий не только RPM-пакеты.

Инженер Red Hat, Peter Zijlstra, переделал механизм CPU hotplug в ядре.

Еще совсем недавно, технология добавления микропроцессоров без остановки системы не была очень актуальной для пользователей. Лишь счастливые системные администраторы мэйнфреймов (администрирование мэйнфрейма дает почетное право запостить скриншот с настоящим мэйнфреймовым uname -a, на зависть администраторам Linux-систем) рассказывали, как здорово на лету заменять микропроцессоры без остановки системы. Обычно, количество микропроцессоров в системе изменялось лишь в момент выключения. Все изменилось с массовым внедрением облачных систем и виртуализации. Пользователи все чаще спрашивали - если мы абстрагировались от "физического" оборудования, то можем ли мы добавлять ядра в виртуалки в ЧНН, и отбирать их позже? К сожалению, несмотря на практическую ценность и техническую реализуемость в Linux, делать это не советовали (например, можно обратить внимание на доклад Михаила Кулемина о динамическом управлении ресурсами в KVM c прошедшего Fedora Virtualization Day). Одной из причин была низкая эффективность ряда механизмов в ядре, используемых при подключении и отключении микропроцессоров. Как раз этим и занялся Peter.

В статье на LWN история изменения описана подробно, а мы лишь вкратце раскажем. Суть в том, что нельзя просто так подключить и отключить ядро - kernel должен быть готов к этому. Любой поток может заблокировать CPU hotplug, и сейчас делается так - есть две функции, get_online_cpus() и put_online_cpus(). Первая увеличивает специальный глобальный счетчик на единицу, каждый раз, когда вызвана, а вторая, соответственно, уменьшает на единицу. В каждой из этих двух функций, код очень простой и понятный. Например, в get_online_cpus():

mutex_lock(&cpu_hotplug.lock);
cpu_hotplug.refcount++;
mutex_unlock(&cpu_hotplug.lock);

Чтоб произвести добавление или удаление ядра нужно дождаться, пока счетчик cpu_hotplug.refcount упадет до нуля, захватить мьютекс cpu_hotplug.lock, изменить количество ядер, и отпустить мьютекс cpu_hotplug.lock.

Простой и понятный, к сожалению, совсем не означает "эффективный" и "быстрый". Проблема в том, что изменение количества ядер происходит редко (как уже было сказано, порой один раз за время работы машины), а вот вызывать get_online_cpus/put_online_cpus система может очень часто. Это приводит к серьезной потере производительности, т.к. захват мьютекса и изменение глобального счетчика затрагивает сразу все процессорные ядра системы (на то они и глобальные объекты). Peter пришел к выводу, что для задачи требуется написать специализированный механизм синхронизации, не использующий мьютексы почти никак.

Для начала Peter разделил все потоки на две группы - те, кто полагаются на неизменное количество ядер ("читатели", которые вызывают get_online_cpus/put_online_cpus), и те, кто устанавливают его ("писатели"). Peter решил сделать так - заведем по одному локальному счетчику количества "читателей" на каждом из ядер микропроцессора, так, что его увеличение или уменьшение будет работать независимо от других ядер, а вот "писатель" будет устанавливать специальный глобальный флаг, перенаправляющий новые процессы "читателей" по старому, медленному пути, ждать завершения уже стартовавших процессов быстрых "читателей" (обнуление всех локальных счетчиков "читателей"), а уж потом начинать изменение используя старый медленный алгоритм.

Подключение процессора это немного замедлит, зато ускорит работу "читателей". К процессу обсуждения механизма подключился его коллега из Red Hat, Oleg Nesterov, предложивший вариант уменьшения времени ожидания "писателем" с использованием RCU, что еще улучшит ситуацию.

Изменение можно ожидать начиная с версии 3.13 - вряд ли успеют в 3.12.

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

Только мы похвалили их за правильный выбор, как они начали колебаться. Коммьюнити Debian вновь парализовало во время выбора из Upstart и systemd. К счастью технический комитет наконец-то примет решение по вопросу.

Мы уже давно говорим, что SysV доживает свои дни и в Debian, и у участников коммьюнити есть только два варианта движения вперед - перейти на Upstart или перейти на systemd.

Оба варианта потребуют, что уже понятно каждому, отказа от игрушечных ядер (FreeBSD, Hurd и прочие). Немногочисленная оппозиция еще предлагала OpenRC, но он технологически далеко позади, и силами трех сочувствующих гентушников разрыв не сократить. И по нашим предположениям, Gentoo перейдет на systemd по умолчанию гораздо скорее, чем многие считают, благо он там в очень хорошем состоянии.

Интрига достигла пика. Суть в том, что в техническом комитете Debian, из семи его участников есть три человека, которые обязательно проголосуют против systemd - работники Canonical, два из которых и пишут Upstart. Таким образом решение в пользу systemd будет выглядеть божественным чудом.

Конечно, очень жаль, что решение такого уровня принимается настолько заполитизированно, без должного рассмотрения технических вопросов, но одно уже определенно - и SysV, и потенциальные замены, типа OpenRC, умирают прямо на наших глазах. С отказом Debian от SysV, вопрос будет окончательно решен.

Lennart Poettering в столь важный момент попытался еще раз предостеречь Debian от ошибки перехода на Upstart.

Он предлагает перед принятием решения посмотреть в будущее, где Upstart сильно отстает от systemd.

Во-1, это cgroups, управление которым включили прямо в systemd, о чем вы уже слышали. В Upstart такая возможность не предусматривалась, и встроить будет непросто. Конечно, встроить придется - методом копипасты` <>`__, как обычно.

Сначала ругают, затем копипастят, ничуть не смущаясь и не извиняясь за ранее сказанное, такова профессиональная честность разработчиков Upstart. Конечно, с другой стороны, чем больше systemd внутри Upstart, тем лучше - и код проверенный, и разница сокращается.

Второй момент, это kdbus. Он изначально разрабатывался с оглядкой на systemd, и разработчики systemd являются разработчиками kdbus. Попытка впрыгнуть сюда у разработчиков Canonical приведет к тому же результату, что и пх попытка оторвать logind от systemd - они потратили несколько месяцев, и сейчас сидят с устаревшим logind. А у systemd сейчас совершенно новая схема user sessions, о чем мы вам уже рассказывали, и Canonical придется переделывать все почти с самого начала. Это еще и приведет к проблемам с Wayland, который вскоре будет полностью требовать systemd (и это будет требоваться для KDE и прочих рабочих столов, которые переходят на Wayland, не говоря уж об их прямых зависимостях от компонентов systemd).

И тут пора сказать вот что. Как ни крути, но будущий Linux сейчас в основном разрабатывается в рамках одного проекта, systemd. Лидер проекта Debian прекрасно осознает вынужденное техническое отставание Debian, и если сделать ставку не на перспективный, а на догоняющий, изолированный по политическим мотивам продукт, то исправить ситуацию в полном объеме не получится. Выбор таков - Debian возвращается к лидерам OSS-мира, либо застревает в песочнице, в которой Canonical пытается заработать деньги, вместе с Mir, Unity и прочими полуоткрытыми технологиями, созданными ради контроля. Все очень просто.

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

Инженер Parallels, Pavel Emelyanov, выпустил CRIU версии 0.8 (в Fedora уже собрана).

Участник Fedora, инженер Red Hat, Karel Zak, выпустил util-linux версии 2.24.

Наши друзья в Eucaliptus выпустили версию 3.4 своей одноименной облачной системы. Из новых фич релиза, хотелось бы отметить интеграцию с Riak CS.

Инженер Red Hat, Jim Meyering, объявил о выходе grep 2.15. В этом релизе особенно хочется отметить опциональное использование JIT-компилятора из PCRE, что сильно ускорит работу.

Maksim Melnikau, инженер Wargaming, побывал на LinuxCon Europe 2013 и изложил запомнившееся в виде презентации.