Интервью с разработчиком Debian о текущей ситуации в проекте

Как вам наверное известно, Debian сейчас переживает непростые времена — уход разработчиков, создание форка и длинные дискуссии о systemd. Об этом мы решили спросить у человека, который непосредственно знаком с обстановкой внутри проекта.

 

— Приветствуем. Для начала представься читателям — кто ты и чем занимаешься в Debian?

— Зовут меня Евгений. Я один из более чем тысячи разработчиков Debian. В 2008-м году я присоединился к проекту, в 2009-м получил право голоса и загрузки пакетов в основной репозиторий.

В Debian я занимаюсь поддержкой некоторых малых пакетов (htop, fbreader, ncdu, bindfs и другими), а также являюсь автором одного из альтернативных
менеджеров пакетов высокого уровня по имени Cupt. Также около двух лет я был Application Manager, то есть одним из тех, кто занимается проверками знаний и умений кандидатов в официальные разработчики.

 — Давай начнем с последних событий. Относительно недавно в проекте Debian был референдум по поддержке в пакетах других систем инициализации кроме systemd. Брал ли ты участие в нем и каков был твой выбор? Твое личное отношение к systemd?

— Да, я поддерживал идею референдума. Мой голос — “12245”, иными словами я предпочёл вариант Яна Джексона (“неспециальным пакетам не следует быть завязанными на конкретную реализацию init”) первым. Варианты “дальнейшее обсуждение” и “решение не нужно” я оставил на последних местах, ибо считал, что обсуждено достаточно и любое конкретное решение лучше неопределённости.

Как можно заключить из цифр выше, я довольно негативно отношусь к подходу к разработке и внедрению systemd. Считаю, что несмотря на возможные технические преимущества проект является угрозой экосистеме Unix-like операционных систем, представляя собой так называемый “vendor lock-in”.


— Почти все время дистрибутивы на базе Linux конкурируют с проприетарными
операционными системами, а в этом случае мы наблюдаем конкуренцию изнутри между свободными проектами. В чем именно заключается опасность systemd, который распространяется под лицензией LGPL и разрабатывается людьми с нескольких компаний (в том числе Red Hat, Canonical, Intel, Collabora и другими) и также независимыми разработчиками? Возможен ли vendor lock-in проекта с открытым исходным кодом? Кстати, совсем забыл — этот вопрос напечатан на машине с systemd (какой ужас!) ☺.

— В объединении под одним деревом исходных кодов ранее не связанных между собой компонентов, а также агрессивными и спорными действиями,
противостоять которым сложно из-за всё более монопольного положения.

Что касается vendor lock-in, то “завязка” на ПО слабо зависит от лицензии и списка разработчиков. Представим себе, что завтра исходные коды Microsoft Windows станут доступны под лицензией LGPL, и в коде обнаружится вклад сотрудников компаний Red Hat, Canonical, Intel и Collabora. Поможет ли это хоть на йоту человеку, пытающемуся портировать WinAPI-приложение на не-Windows платформы?

Степень завязки определяется, в первую очередь, объёмом ПО, его связанностью, степенью стандартизации интерфейсов, а также политикой
лидеров.

Я люблю аналогии и приведу ещё одну: представьте себе, что новая компания начала продавать дешёвые пятиугольные столы, к которым хорошо подходят лишь пятиугольные стулья (той же компании) и на которые можно ставить лишь пятиугольные чашки и тарелки (той же компании). Столы, стулья и столовые приборы продаются одним комплектом. При замене стула потребуется заменить также все остальные остальные стулья и стол. Четырехугольные стулья объявлены устаревшими, а поддержка круглых стульев и стульев-расладушек удалена совсем. Идут переговоры со строительными компаниями о переходе на пятиугольные комнаты для лучшей
интеграции.

— Было ли давление со стороны Red Hat и Canonical на разработчиков перед референдумом? Известно, что в техническом комитете есть сотрудники Canonical(в том числе бывшие) и многие разработчики работают в обоих проектах.

— Доказательств или признаков давления я не видел и склонен считать, что результат отражает мнение самих разработчиков. Другое дело, что окружение (рабочее и в Debian) вполне естественно влияет на позиции — неудивительно, что среди сопровождающих GNOME так много сторонников
systemd.

— После этого голосования ушло 5 опытных разработчиков с технического комитета и с проекта в целом. Как все это повлияло на обстановку внутри?

— В основном негативно, конечно, но были и интересные положительные моменты. Жаркие обсуждения вскрыли глубокие различия в мнениях групп разработчиков о том, в какую сторону следует развиваться проекту и какие компромиссы допустимы. Смею предположить, что немалое количество представителей “победившей” платформы были несколько удивлены упорством людей, которым не всё равно, что под капотом базовой системы. В свою очередь, “оппозиционеры” не понимали, как можно обменять принципы
и возможность выбора на пару технических плюшек.

В культуре Debian пропагандируется принятие решений методом консенсуса — иными словами обсуждения до тех пор, пока не будет найден хороший компромисс, и не потребуется голосовать. Обсуждаемый вопрос — один из немногих на моей памяти, по которому даже хрупкого консенсуса достичь не удалось, и пришлось голосовать — сначала техническому комитету, а потом
и всему проекту.

Даже сейчас, после всех этих голосований, то и дело в список рассылки пишут люди, призывающие предпочесть тот или иной вариант.

— Появление Devuan, форк Debian GNU/Linux без systemd — насколько по-твоему реальны шансы форка быть успешным? Планируешь ли ты брать в нем участие?

— Зависит от количества компетентных разработчиков. Мы знаем примерное число тех разработчиков Debian, кто поддерживает идею, но мы не знаем, у кого из них есть время и силы поддерживать форк (а они потребуются, особенно на первых порах). Также интересно узнать, кто именно стоит за “Veteran Unix admins”.

Брать участие — возможно, зависит от многих факторов — собственного времени, культуры сообщества и основателей, а также востребованности своих умений. Как минимум, я буду с интересом следить за Devuan и ему подобными.

— Много ли русскоязычных разработчиков Debian? Если тебе трудно судить о всех, то только тех с которыми ты знаком лично.

— Неофициальная статистика по странам утверждает, что летом 2014 года в России проживало 9 официальных разработчиков, 2 в Беларуси и 1 на Украине. Конечно, эта статистика не говорит о том, кто какими языками владеет — например, я не вхожу в вышеназванные 12. Кроме того, в те 12 также не входят те, кто выполняет полезную работу, но (как правило) не имеет права голоса — переводчики, художники, активно сообщающие об ошибках и другие.

Я лично знаком с двумя, и ещё с двумя-тремя посредством электронной почты.

— Существуют ли какие-то “площадки” для общения и взаимодействия русскоязычных разработчиков?

— Есть площадки для разработчиков и пользователей, например IRC-канал #debian-russian (цитата [1] именно оттуда ☺ ), а также одноимённый список рассылки [2]. Площадок только для разработчиков на русском я не знаю.

[1] [2]

Вопросы задавали Paul Carroty и пользователи DebianForum.ru.

  • IvanKorjavin

    Отличное интервью.

    • Paul Alberto Rufous

      спасибо.

  • Интервью интересное.
    Но раз затронули systemd могу сказать, что после 2-х лет использования systemd я не могу пользоваться другими системами инициализации. Мне нравится использовать systemctl enable service вместо каких-то неизвестных комманд, которые нужно для каждого пакета еще и гуглить. Мне также нравится простым способом написать сервис (к примеру в несколько строчек запуск xvfb который автоматически перезапускается если падает) и включить его в автозапуск. Мне также нравится что я забыл о watchdog’ах для перезапуска сервисов, один параметр в файле сервиса, и systemd автоматически перезапускает сервис если он падает.

    Конечно мое мнение не претендует в качестве полностью объективного, но мне нравится заниматься работой, а не гуглением как добавить сервис в автозагрузку после запуска другого.

    • Paul Alberto Rufous

      Пожалуй могу подписаться под этим.