Интервью Леннарта Поттеринга (Lennart Poettering) о systemd, PulseAudio, kdbus, шоколаде, хейтерах и других интересных вещах

Леннарт Поттеринг: "Я не использую проприетарное ПО ни на одной из моих машин"

После интервью с одним из разработчиков проекта Debian, который считает systemd угрозой, и победы Леннарта Поттеринга в открытом новогоднем голосовании на звание "Человека года 2014", мы решили дать слово противоположной стороне. Леннарт любезно согласился на перевод cвоей сессии с пользователями Reddit.

- Каков твой следующий большой проект?
- systemd! Учитывая масштаб этого проекта, основным для меня он останется надолго.

- Должны ли ядро и systemd обновляться одновременно? Если да, рассматривается ли вопрос о принятии в systemd графика релизов, соответствующего ядру, и аналогичной нумерации версий?
- Вообще мы стараемся сохранять совместимость systemd cо всеми версиями ядра за последние два года. Несмотря на то, что я рекомендую обновлять ядро и systemd одновременно, сейчас в данном отношении всё обстоит довольно гибко.

- В чём причина того, что systemd отошёл от традиционной схемы версионирования с несколькими компонентами (например, "2.34.1")? Это позволило бы легче узнавать релизы с большим количеством изменений - или те, в которых меняется API.
Есть ли особые планы на версию 666? Объединить код с ядром, например?
Как обстоят дела с новым подходом к организации дистрибутивов [речь об этой статье - прим. пер.]?

- Мы бы хотели стремиться к частому выпуску новых версий с относительно небольшим количеством изменений в каждой. Именно поэтому нумерация версий у нас линейная. На самом деле, наша цель - новый релиз каждые 2-3 недели, но сейчас у нас не очень получается. Насчёт API - мы пытаемся быть очень консервативными в вопросах сохранения обратной совместимости (разумеется, только тех интерфейсов, что помечены как стабильные). А до версии 666 ещё далеко, так что спросите меня об этом поближе к релизу!
Относительно нового подхода к построению дистрибутивов: мы в настоящее время работаем над вещами из более низких слоёв (например, над kdbus), и нам потребуется некоторое время, чтобы с ними всё закончить.

- Учитывая весьма быстрый релизный цикл systemd, как вы обеспечиваете стабильность релизов? Есть ли у вас периоды заморозки (feature freeze)?
Вообще говоря, 2-3 недели на релиз - это очень мало. Мне интересно, существуют ли другие проекты с подобным графиком. Таким дистрибутивам, как Arch, придется тяжело: ключевые компоненты, такие, как systemd, сначала проходят испытания в тестовом репозитории, и эта фаза может занимать неделю или две.
- systemd не является компонентом, который пользователь будет устанавливать по желанию поверх своего дистрибутива. Это действительно ключевой компонент дистрибутива, и его разработчикам придётся проделать определенную работу по интеграции. Поэтому: выбрать релиз systemd, интегрировать его и стабилизировать при необходимости - это задача разработчиков дистрибутива.
Обратите внимание, что на самом деле у нас сейчас есть "стабильная" ветка, которая совместно сопровождается разработчиками из Debian, Fedora и RHEL. Им всё равно приходится выбирать себе конкретные версии и потом бэкпортировать туда необходимые исправления. Поэтому дистрибутивы могут пользоваться этими результатами вместо того, чтобы постоянно пить из пожарного шланга. Также мы отдельно помечаем (с помощью "git notes") все коммиты, которые считаем пригодными для бэкпортирования, чтобы упростить дистрибутивам их работу.

- Учитывая количество критики, которое вы получаете насчёт systemd и прочих своих проектов, задумывались ли вы о том, чтобы прекратить работу в open source?
- Нет. Я уже выработал некоторую "толстокожесть" относительно этого, и тот объём ненавистных комментариев, которые мы (как команда разработчиков systemd) иногда получаем, не особо на меня влияет.

- Достиг ли проект PulseAudio каких-либо из своих первоначальных задач, и что еще предстоит cделать?
- Сейчас я не очень вовлечен в разработку PulseAudio, так как его сейчас поддерживает другая команда разработчиков, и они прекрасно знают своё дело.
Когда я только начинал работу над PA, моей единственной целью было написать звуковой сервер, лучший, чем "EsounD" (очень примитивный и очень старый сервер из графического окружения Enlightenment). На мой взгляд, эту цель мы достигли уже давно.

- Тот объём нетехнической критики, который вы получаете насчёт своей работы, ни разу не заставлял ли вас задуматься, что, может быть, стоило бы поменять собственный характер и сделать его менее грубым и отталкивающим?
- Я в значительной степени уверен в том, что большинство людей, думающих, что мы грубые и упертые, никогда не пытались с нами общаться. Поэтому я не думаю, что мы на самом деле настолько плохие.
Вот что я имею в виду: естественно, всегда были и будут такие места, где мы будем говорить "нет". Но когда мы это делаем, мы стараемся давать достаточные технические объяснения происходящему. Конечно, когда вы не получаете функциональность, которую хотели больше всего, это разочаровывает, и поэтому порой люди говорят, что мы их не слушаем. Но на самом деле мы слушаем, просто не всегда соглашаемся.
Да, многие из тех, кто работает над systemd, имеют стойкие мнения и убеждения, и мы не пытаемся их скрывать. Я думаю, некоторые из нас (включая меня) могут при этом очень непосредственно при этом выражаться (я полагаю, что это своего рода немецкий стиль). Но, в целом, мы - люди технические, и если у вас есть техническое предложение, то мы в любом случае его рассмотрим.
Сообщество systemd, вообще говоря, сейчас весьма обширно и по большей части доброжелательно. Просто обратите внимание на объём корреспонденции, который мы сейчас имеем в списке рассылки! Я думаю, что большинство людей на самом деле вполне довольно тем, что представляет собой наше сообщество. Мы стараемся ответить на каждое сообщение, которое мы получаем (хотя иногда могут быть небольшие задержки вследствие большого количества писем). И мы в действительности реализуем большую часть просьб от сообщества.
А атмосфера внутри сообщества systemd, в наших списках рассылки и на IRC-каналах, сейчас определённо лучше, чем в LKML (списке рассылки ядра Linux). Не уверен, что LKML является примером хорошего поведения людей, но я могу заверить вас, что на systemd-devel гораздо лучше, чем там!

- В каких юзкейсах будет наиболее заметно то увеличение производительности, которое привнесёт kdbus после своего внедрения? Какие виды нагрузок выиграют больше всего?
- Kdbus прежде всего является интересным для тех людей, которые работают в нижних слоях программного обеспечения. На стороне systemd к kdbus прилагается новый набор инструментов, который, как мы надеемся, лучше раскроет возможности dbus для системных администраторов (например, упростит взаимодействие с шиной из скриптов), однако, строго говоря, это не особенность kdbus как такового. Если мы сделаем все правильно, то для пользователей очень мало что должно измениться. [Когда kdbus был впервые представлен, упоминалось, что преимущества в плане производительности будут наиболее заметны во встраиваемых системах - например, в автомобильных - и вообще там, где через шину передаётся очень большое количество сообщений. Типичные десктопы, равно как и серверы, такой особенностью не обладают, и преимущества ожидаются исключительно структурные. - прим. пер.]

- Планируется ли расширение интеграции с пространствами имён ядра Linux? Например, "запустить указанный демон в указанном сетевом неймспейсе"?
- У нас в планах есть некоторое количество связанных с этим функций. В частности, мы хотим добавить возможность назначения socket-юниту того же самого сетевого пространства имён, как и активируемому юниту, и тому подобное.

- Какой твой любимый шоколад?
- Это очень хороший вопрос. Я люблю швейцарский шоколад. Lindor, например, или Frigor.

- 1. Когда разработка systemd только начиналась, ты ожидал столько споров и полемики? Были ли вы удивлены количеством шума и криков в сторону systemd?
2. Что будет твоим следующим проектом после systemd и kdbus? Что, по твоему мнению, стоит дорабатывать в линуксовом юзерспейсе в первую очередь?
- O да, мы весьма хорошо это представляли. В частности, у нас с Кеем Сиверсом уже был опыт подобной разработки, и мы точно знали, что убедить в чём-то техническое сообщество будет проблематично, равно как и иметь впоследствии дело с оравой несогласных.
Обратите внимание, что лично я не работаю над kdbus вплотную; я лишь внёс несколько исправлений. Моим проектом является systemd, и, учитывая масштаб этого проекта, найдётся ещё огромное множество вещей, которые предстоит сделать, прежде чем мне придётся искать новый проект... systemd - один из тех "бесконечных" проектов, которые должны развиваться вместе с остальными частями экосистемы - и, на самом деле, со всей отраслью IT.

- Как можно присоединиться к разработке systemd? Сколько человек сейчас работают над этим проектом? Есть ли у вас задачи для новичков [junior jobs - прим. пер.], как в проекте Kernel Janitors?
- Есть много способов поучаствовать в разработке systemd. Большинство из нас присутствуют на канале #systemd в сети Freenode. Там (и в нашем списке рассылки) вы можете познакомиться с разработчиками. У нас есть 26 постоянных разработчиков, причём из разных компаний: Red Hat, Canonical, Intel, Collabora ... Впрочем, это именно те, у кого есть право записи в репозиторий; помимо них есть множество других людей, присылающих патчи (которые затем рецензируются кем-то из тех двадцати шести людьми). Если верить Ohloh, то каждый месяц в systemd добавляется код от ~40 разных людей.
У нас в репозитории есть TODO-список, где мы кратко перечисляем разные вещи, которые нужно когда-нибудь сделать. Некоторые из них реализовать проще, некоторые - труднее. Этот список -- хорошее место для того, чтобы ознакомиться с текущими планами и найти себе задачу. Вы всегда можете более подробно расспросить нас в списке рассылки или на IRC-канале.

- systemd, как "объединяющий" проект, так или иначе всегда будет обладать некоторой поверхностью атаки ["attack surface"]. Что уже сделано и что нужно сделать для обеспечения безопасности?
- Поскольку в действительности проверки исходного кода проводятся весьма редко, я полагаю, что нужно увеличивать степень обобщения кода между различными проектами и отдельно унифицировать "чувствительный" код.
Единый способ управления службами также позволяет нам достичь большей безопасности. Она является для нас приоритетом, и мы работаем над соответствующей функциональностью в systemd, чтобы сделать операционные системы более безопасными по умолчанию. Я более подробно рассказывал об этих вещах в своём недавнем выступлении.

- systemd продолжает в быстром темпе добавлять новую функциональность. Будет ли systemd обновлён до последней версии в какой-то из ревизий RHEL 7.x? Или RHEL 7 / Centos 7 будут продолжать использовать ту версию systemd, которая есть сейчас?
- В рамках RHEL 7 я бы скорее ждал отдельных бэкпортов, нежели обновления до последней версии. А в RHEL 8, разумеется, обновление будет.

- После того, как завершится интеграция systemd в основные дистрибутивы Linux (Debian/Ubuntu, RedHat, Arch), большинство производных дистрибутивов (Mint, Elementary, CentOS, Manjaro) последует их примеру. Это даст "техническому комитету" systemd (если таковой существует) некоторое влияние над подавляющим большинством дистрибутивов.
Будет ли команда/"комитет" systemd включать в себя разработчиков или пользователей этих дистрибутивов? Помимо разработчиков RedHat/Fedora или Debian. Если да, то будут ли эти разработчики из других дистрибутивов иметь право голоса относительно пути развития systemd?
Какая часть трилогии The Matrix является вашей любимой?
- Я не могу отрицать, что мы, как команда разработчиков [широкоиспользуемого] апстрима, получили порядочную степень влияния. Тем не менее, не мы занимались интеграцией systemd в дистрибутивы; это делали их разработчики. Мы даём базовые рекомендации о том, как следует поставлять и использовать компоненты systemd, но вообще это не наше дело. Дистрибутивы регулярно многое переделывают или вносят изменения в код, и это абсолютно нормальная ситуация. В самом деле, даже Fedora и RHEL иногда делают некоторые вещи по-другому, при том что я сам участвую в сборке systemd для этих дистрибутивов! Мы предоставляем основу, а дистрибутивы затем адаптируют её к своим нуждам.
Мы стараемся обеспечить разнообразие в команде разработчиков systemd; сделать так, чтобы она отражала мнение сообщества в целом. Среди нас есть люди из Debian, Canonical, Mageia и Tizen (о Fedora/RHEL вы наверняка уже догадались). Вообще говоря, одна из наших задач - это плавно прекратить управлять происходящим. Это должно стать противоположностью проекту Upstart, где всё было построено на контроле Сanonical c помощью передачи прав на код [речь о Contributor"s License Agreement, которое даёт Canonical возможность в будущем перелицензировать свои проекты - прим. пер.] и ещё много чего, что определённо поспособствовало окончательному провалу проекта.
Конечно, нет никаких сомнений, что мы сейчас располагаем некоторым влиянием, но мы стараемся сотрудничать со всеми желающими, и даже выдаём при необходимости права на запись в репозиторий.
Вообще говоря, мы хотим, чтобы systemd двигался быстрыми темпами, и поэтому создание официальных "комитетов", принимающих технические или иные решения [насчёт systemd], очень маловероятно.
[вопрос про The Matrix был, по всей видимости, проигнорирован. - прим. пер.]

- Какова, на твой взгляд, самая интересная из малоизвестных функций systemd?
Если бы у тебя были планы на интеграцию в systemd собственного менеджера пакетов, на что бы он был похож?
- Хм, наверное, это "systemd-nspawn" - небольшая утилита, управляющая контейнерами. Эта вещь тривиальна в использовании, причём её код весьма прост, поэтому она мне нравится. В настоящее время при тестировании systemd я в основном пользуюсь именно ей, потому что это действительно удобно. Если вы еще не пробовали, то попробуйте. Похоже на `/usr/bin/chroot`, но куда мощнее и более автоматизированно.
Что касается управления пакетами: я думаю, что RPM и dpkg и так достаточно хорошо справляются с этой задачей. Впрочем, у нас есть некоторые планы насчёт контейнеризации приложений, и мы бы хотели однажды их воплотить. Это всё описано здесь.

- Я пытался использовать systemd-nspawn для запуска Arch Linux ARM на моем Galaxy Nexus, который работает на Sailfish OS, но получил уведомление об отсутствии в ядре поддержки пространств имён. Возможно, придется пересобрать ядро с другой конфигурацией.
Что должно находиться в контейнере, запускаемом с помощью nspawn? Я подготовил с помощью pacstrap корневую директорию, в которую поместил только systemd, и это сработало - но суммарный размер зависимостей оказался достаточно велик, да и сам пакет systemd не является примером минималистичности. Мне бы хотелось, чтобы контейнер занимал порядка 10 мегабайт.
- На самом деле, nspawn способен запустить контейнер и без системы инициализации. Если вы хотите достичь абсолютно минимальной конфигурации, то вы могли бы просто запускать в контейнере один статически слинкованый бинарник или, например, командную оболочку. А минималистичность самого systemd зависит от дистрибутива. Если рассматривать апстримную версию, то systemd имеет лишь две жёсткие зависимости: libc и libcap [последнюю скоро уберут - прим. пер.], а большинство компонентов являются необязательными и их можно отключить при компиляции.

- Я тоже пытался экспериментировать с systemd-nspawn. Я написал скрипт, который устанавливает Arch, и собирался заменить в нём arch-chroot на systemd-nspawn, чтобы запускать внутри контейнера systemd и использовать такие вещи, как localectl. При этом у меня возникли некоторые проблемы. Например, не получилось указывать выполняемые внутри контейнера команды в виде here-файла:
arch-chroot /mnt << HERE
command1
command2
HERE

Соответственно, это не работает:
systemd-nspawn -bD /mnt << HERE
command1
command2
HERE

Также я не знаю, как заставить его автоматически входить в систему от имени суперпользователя.
- Флаг "-b" заставляет systemd-nspawn загрузить контейнер вместе с системой инициализации. Если вы его не укажете, то получите шелл. Если вы просто хотите запустить несколько команд внутри контейнера -- тогда уберите "-b". Это будет похоже на запуск ядра на с параметром init=/bin/bash.

- Я пробовал так делать, но, видимо, остаюсь на arch-chroot, поскольку без флага "-b" нельзя использовать такие команды, как localectl.
- Это есть у нас в TODO - возможность передачи через параметры ядра списка команд, которые необходимо выполнить. Мы бы тогда могли на лету создавать из этих команд юнит-файл [по аналогии с systemd-run - прим. пер.], запускать его как основную цель и сразу по окончании его работы останавливать систему. Это позволит автоматизировать выполнение произвольных команд на полностью запущенной системе. Кстати, это будет полезным не только для контейнеров, но и в случае KVM, или даже безотносительно виртуализации...

- Какие будущие возможности ядра Linux волнуют тебя больше всего? Возможность обновлять ядро во время работы системы сейчас выглядит ужасно привлекательной.
- Конечно, kdbus! Я очень надеюсь, что его быстро примут в ядро. Это позволит сделать в systemd много нового, так как в настоящее время нам приходится воздерживаться от использования dbus во время ранней стадии загрузки системы. К слову, именно поэтому journald и networkd сейчас не имеют шинных интерфейсов.

- 1. Занимаешься ли ты продвижением Linux на десктопах работников Red Hat? Как ты считаешь, новая Fedora Workstation может этому помочь?
2. Может ли недавний ошеломляющий успех OSX среди разработчиков создать фундаментальное препятствие развитию Linux? Или он в основном не имеет отношения к прогрессу ключевых Linux-технологий?
3. Может ли Linux предложить разработчикам что-нибудь взамен Homebrew [пакетного менеджера OSX]?
4. Каков твой любимый язык программирования на данный момент?
И спасибо за весь твой тяжелый труд.
- Относительно 1: Вероятно, я не понял этот вопрос. Вообще говоря, Red Hat Enterprise Linux уже является основной десктопной операционной системой в Red Hat. Большинство инженеров в RH тоже используют Fedora.
Относительно 2: Конечно, будет лучше, если все эти люди станут использовать и совершенствовать Linux вместо OSX, но опять-таки я полностью уверен, что Linux будет существовать ещё долго после того, как OSX не станет.
Должен признать - я понятия не имею о том, что такое homebrew.
А что касается языков - я предпочитаю C. Он во многом неудобен, но сейчас я использую его почти исключительно, и это определённо лучший язык среди тех, что я знаю. Если вы разрабатываете что-то низкоуровневое или системное, то у вас, пожалуй, нет выбора.

- Относительно всей той сложности, которую в конечном счёте приобрели PulseAudio и systemd: как ты относишься к принципу UNIX "делать что-то одно, но делать это хорошо"? С точки зрения 2014-го года этот подход всё ещё актуален?
- Истинные UNIX-системы, как правило, держат в одном репозитории достаточно много компонентов: как минимум, ядро, libc и большую часть основного юзерспейса.
UNIX-модель заключается в том, что всё делается в одном и том же месте с общим релизным циклом, а традиционная модель Linux - это когда разработка ведётся индивидуально, все репозитории раздельны, а стили программирования, релизные циклы и тому подобные вещи могут быть сколь угодно различными. Я считаю, что лучше всего будет нечто среднее, и в systemd мы пытаемся сделать именно это: сократить количество "строительных блоков", при этом не сводя его к единице. Кроме того, давайте не забывать, что для Linux сейчас существует несколько юзерспейсов Linux (например, Android...), и это тоже хорошо.

- И еще: должны ли проекты, подобные systemd, включаться в ядро?
- systemd разделен на большое количество отдельных компонентов (сейчас мы собираем чуть более 90 бинарных файлов). Каждый из них мы запускаем с минимально возможными привилегиями. В некотором смысле, это и есть "делать что-то одно, но делать это хорошо". Кроме того, мы просто упаковываем много вещей в один пакет.
Я полагаю, это не слишком отличается от того, что делают в coreutils - он также представляет собой большое количество компонентов в одном пакете. Наверное, сoreutils является одним из основных проектов, позволяющих Linux быть UNIX-подобной ОС, не так ли?
Но да, systemd сложнее, чем sysvinit, в этом нет никаких сомнений. За последние 40 лет в нашей индустрии поменялось много всего, и от софта подчас требуется определенный уровень сложности... С этим ничего не поделаешь.

- Как у вас получается балансировать между позитивными и негативными отзывами пользователей по поводу новой функциональности и вообще изменений в проекте? Влияет ли обратная связь на принятие решений, или вы основываетесь исключительно на собственной интуиции и техническом обосновании? Мне кажется, что в каждом кругу пользователей есть своя "крикливая" группа людей, которая заявляет о множестве проблем с systemd, но вместе с ними можно найти и много тех, кто не против изменений или приветствует их.
- Systemd является проектом с открытым исходным кодом, и, следовательно, существует благодаря сообществу и его вкладу. Если кто-то отправляет в список рассылки патч, или же просит о добавлении новых возможностей, то мы действительно ценим это. Конечно, мы не делаем всё, о чём нас просят, но я думаю, что мы учитываем больше пожеланий, нежели отвергаем. Конечно, у нас регулярно возникают обсуждения по различным вопросам внутри сообщества и внутри команды разработчиков, и мы решаем, что будем делать, а что - нет. До сих пор у нас не было проблем с достижением консенсуса, так или иначе удовлетворяющего большинство участников.
Мы никогда не делаем что-либо, исходя из интуиции. По крайней мере, пытаемся так не делать. Мы являемся техническими людьми, а systemd - техническим проектом, поэтому именно объективные технические критерии мы считаем самыми важными.

- Я хотел бы узнать, как в действительности можно внести свой вклад в проект. Существует ли место, где доступен план работ и список тех, с кем можно поговорить, чтобы получить первое представление о происходящем и начать присылать патчи? Другими словами, хотелось бы избежать ситуации, в которой патчи будут отвергнуты, а работа окажется проведённой впустую.
- Нет никакого плана работ. У нас есть TODO-список, в котором перечислено то, что нужно так или иначе сделать. Там всё очень лаконично, поэтому за подробностями обращайтесь в список рассылки или на IRC-канал.

- Некоторые технически компетентные люди считают, что последние нововведения в dbus и kdbus преследуют цель обхода ограничений GPL. Например, вот здесь.
- Какой ужас. Должен признаться, что о такой теории заговора я никогда не слышал!
Я могу заверить вас, что kdbus вообще никак не относится к лицензированию. И чем вообще kdbus отличается от dbus в этом плане? В самом деле, текст по ссылке применим к любому виду IPC, будь это dbus, CORBA, UNIX-конвейеры или что угодно ещё. Утверждение о том, что хороший IPC нужен ради обхода лицензионных ограничений, звучит совершенно дико на мой взгляд. В действительности IPC - это одна из фундаментальных вещей, на которых строится любая ОС, и так было с самого начала.
Например: ядро GNU Hurd - это микроядро, а они традиционно обладают весьма "продвинутыми" реализациями IPC. Ядрa, основанные на Mach, имеют концепцию "портов" - это IPC, которая лучше, чем что угодно из мира Linux - и Hurd построен как раз вокруг этой концепции. Хотите сказать, что проект GNU пытается таким образом обойти GPL?
Я не использую проприетарное ПО ни на одной из моих машин. Не столько из философских причин, сколько потому, что его просто неприятно использовать. Его даже невозможно при необходимости поправить.