Оценка плюсов и минусов при переходе Debian на systemd или upstart

[Malaheenee]

Интрига продолжается:

Бидейл Гарби (Bdale Garbee), председатель Технического комитета Debian, объявил итоги третьего голосования по вопросу перехода следующего выпуска Debian на новую систему инициализации. В голосовании победил systemd, который будет использован по умолчанию в Debian GNU/Linux Jessie. Четыре участника технического комитета проголосовали за systemd, а четыре отдали предпочтение upstart. Для разрешения конфликта интересов Бидейл Гарби, как председатель, воспользовался правом дополнительного голоса.
Решение может быть пересмотрено путем проведения референдума среди всех разработчиков Debian. В резолюции указано, что в случае если большинство разработчиков Debian отдадут предпочтение системе инициализации отличной от systemd, то такое решение будет иметь более высокий приоритет и будет автоматически утверждено техническим комитетом. С учётом большого числа разногласий в сообществе разработчиков, вероятность проведения общего референдума очень высока.

[qupl]

Вот как сильно беспокоят треугольные дела (с) ВСВ

[Malaheenee]

Рано или поздно до этого бы дошло. Процитируем на всякий случай, а то любят потом новости исчезать:

Один из разработчиков открытого ПО Маас Верри (Maas Verri) разместил в профильной рассылке lists.debian.org предложение физически расправиться с другим участником сообщества - Адрианом (Adrian). Мотивом для призыва к расправе стала инициатива Адриана лишить пользователей выбора системы инициализации в Linux, оставив возможность пользоваться одной-единственной - Systemd.
«Таких людей, как Адриан, которые настаивают на том, чтобы systemd стала единственной системой инициализации в Debian, нужно физически наказать», - предлагает Верри.
«Это диктатура... Они говорят, что хотят «помочь Debian». Видимо, так же, как церковь в средние века «помогала» людским душам, пытая и сжигая людей заживо», - негодует Верри.
«Debian существует для людей. Это не религия. И это не скульптура. Они говорят, что хотят «улучшить Debian». Но Debian существует не ради самого себя, а ради всех нас. Адриан и другие сторонники Systemd пытаются отобрать Debian у нас и отдать его своим "пользователям"», - продолжает Верри.
Ответа Адриана в рассылке нет.

[Udachnik]

Один из разработчиков открытого ПО Маас Верри (Maas Verri) разместил в профильной рассылке lists.debian.org предложение физически расправиться с другим участником сообщества

Какой он разработчик? Что он разрабатывает? Просто тролль отправил письмо в рассылку.

[sandaksatru]

Какой он разработчик? Что он разрабатывает? Просто тролль отправил письмо в рассылку.

Я тут почитал их рассылку. Там вообще полная Ж творится. В адрес Systemd один мат летит. Всё началось, насколько я понял, с конфликта Гарби Бидэйла (председателя технического комитета) и Яна Джексона (автор dpkg) - оба авторитетные люди в Debian. Бидэйлу приспичило во что бы то ни стало быстрее решить вопрос с системой инициализации (само собой он голосует за SystemD), а Ян Джексон наоборот считает, что вопрос требует дополнительного обсуждения, и нельзя спешить с systemd.

Хочу уточнить, что голосование инициировалось так: Бидейл кидает в рассылку письмо с темой "call vote" и вариантами ответа. После второго голосования Джексон просил назначить определенную дату для дня выборов (в частности 18 февраля), и заранее определиться с регламентом. Он также предлагал внести дополнительные варианты, типа "использование нескольких систем инициализации без предпочтения какой-либо", и "вынесение вопроса на всеобщее голосование". В качестве ответа на просьбу Джексона Бдэйл на следующий день инициирует третье голосование с преамбулой в духе "я думаю, Джексон не прав...". И тут с небольшим перевесом победил systemd. Исходя из голосования, если бы systemd не победил, то вопрос был бы отправлен на дальнейшее обсуждение, т.к. остальные голоса разошлись.

Джексон со злости даже объявил вотум недоверия председателю ТК и выдвинул голосование за его отставку. Его, кстати, никто не поддержал. Но напряженная атмосфера сделала своё дело. Ярые сторонники systemd вступили в перепалку с её противниками.

Тот Adrian, которому угрожали рукоприкладством, предложил оставить systemd в качестве единственной системы в Debian, мотивируя тем, что разработчики лучше знают, что нужно пользователям. Естественно, это спровоцировало волну недовольства со стороны, и в его адрес полетела куча мата. Маас Верри, если отбросить нецензурную брань и угрозы, привёл очень даже логичные доводы. Я даже с ним частично согласен (конечно же в той части, которая не касается отдельных личностей).

В рассылке от сторонних людей попадаются очень здравые и интересные мысли. В одном из таких, автор (некто John Mist) разбирает достоинства и недостатки Debian, а также политику компании Red Hat:
https://lists.debian.org/debian-ctte/2014/02/msg00461.html
Приблизительный перевод (прошу строго не судить, с аглицким у меня хреново):

Открыть содержимое (спойлер)

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

Сильные стороны Debian, благодаря которым он превосходит остальные дистрибутивы:

1) Это универсальная операционная система. В минимальной инсталляции она действительно мало занимает места на диске и нетребовательна к оперативной памяти.
2) Она реально быстрая и эффективная.
3) Она полностью управляема специалистами среднего уровня. Она делает только то, что вы хотите, и когда вы хотите.
4) Debian имеет стабильное ядро, остальные пакеты тоже достаточно стабильны.
5) Это лучшая основа для создания реально безопасной, эффективной и надежной системы.
6) Это лучшая система для небольших задач, типа построения web-серверов. http://w3techs.com/technologies/details/os-linux/all/all
6*нумерация из оригинала) Я считаю, его огромная и тщательно протестированная пакетная база является наилучшей отправной точкой для построения нестандартных решений, способных удовлетворить потребности каждого клиента.
7) Debian достаточно консервативен в вопросах управления системой. Это позволяет изучать что-то новое и развиваться, а не учиться каждые пару лет как делать тоже самое, но другим способом.
8 ) Это лучший из всех дистрибутивов, предоставляющих свободу выбора. По крайней мере для квалифицированных людей.

Слабые стороны Debian:

1) Отсутствие разработчиков, которые полный рабочий день могли бы заниматься дистрибутивом. Мы не можем быстро изменить нечто-то большое. Мы не можем вносить изменения часто.
2) У нас не так много девелоперов, работающих над компонентами ядра Linux. Мы не можем повлиять на путь развития самого Linux.
3) Отсутствие "официальной" технической поддержки и возможности тесного контакта с основными разработчиками. У клиентов нет телефонного номера, на который они могли бы позвонить - и всё бы чудесным образом заработало.

Что сегодня твориться в мире Linux:

Существует коммерческая компания "Красная Шапочка". Они делают деньги. Для того чтоб делать деньги, они должны иметь завышенные расценки. Для того, чтоб цены были выше реальной стоимости обслуживания, они должны оставаться одни в этом сегменте рынка. Но в последние годы мы видим тенденцию, как "Красная Шапочка" медленно, но непрерывно уступает позиции лидера в сфере дистрибуции и поддержки Linux.

Я думаю, это происходит из-за двух причин:

1) Агрессивная маркетинговая политика Ubuntu. Множеству новичков Linux более привычна Ubuntu, а не семейство Red Hat дистрибутивов.
2) Устойчивый рост первоклассных специалистов Linux. Сейчас действительно легко найти профессионала для создания под заказ системы любой сложности. И это во многом благодаря Debian как более прозрачной, простой и гибкой ОС, чем Red Hat и её семейство. В то же время - надежной и быстрой, по крайней мере, чем Red Hat.

Какие у "Красной Шапочки" есть козыри:

1) Они имеют прочную репутацию лидера Open Source. Много лет они помогали сделать Linux лучшей оперционной системой всех времен.
2) Они имеют огромное влияние на многих разработчиков экосистемы Linux.
3) Они располагают большим доверием и уважением среди разработчиков Open Source решений.

Что они могут сделать:

1) Они могут изменить схему разработки ядра таким образом, что ядро Red Hat будет иметь преимущества, которые в других дистрибутивах будут появляться со значительным отставанием.
2) Они могут перехитрить сообщество GNU/Linux таким образом, что смогут полностью контролировать его, и любое параллельное развитие будет похоронено под инновациями "Красной Шапочки". Автоматически, все остальные дистрибутивы станут многочисленными его клонами, или ориентированными только для гиков. - Я уверен, именно это сейчас и происходит.

Они разрабатывают и проталкивают продукт, который меняет всю работу системы. Продукт поглощает всё больше и больше системных сервисов от загрузки системы и запуска служб, до авторизации пользователей и логгирования. Естественно это делает систему менее устойчивой и безопасной: http://ewontfix.com/14/

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

Даже на маленьких и простых web-серверах systemd и её дополнительные службы вызовут увеличение необходимой для работы системы памяти и выкинут Debian из сферы низкобюджетных VPS-ок, примерно как сейчас CentOS. Да, провайдеры будут предлагать под Debian VPS-ки с большим объём памяти, но Debian потеряет одно из основных преимуществ перед Red Hat.

Во всяком случае, если "Красная Шапочка" продолжит поглощать задачи системного уровня, то различие между дистрибутивами станет чисто косметическим. (прим. - БолгенОС? ). Зачем тогда нужны будут дистрибутивы с незначительными дополнительными опциями, если у нас есть Red Hat?

В такой ситуации Debian, вероятно, прекратит свое существование. Или мы будем пытаться сделать действительно другой дистрибутив практически с нуля. Но это будет гораздо сложнее, вместо того, чтобы не потерять контроль над экосистемой сейчас.

Я уверен, выбор Systemd в качестве init-системы по умолчанию сделает Debian "одним из многих" и в конце концов уничтожит его.

С уважением,
J

[свернуть]

Я тоже считаю переход на другую систему инициализации решением политическим, а не техническим. Red Hat (в сговоре с SUSE) и Ubuntu постоянно бьются между собой за рынок и за влияние над Debian. Ведь Debian - их главный конкурент, а для кого-то ещё и ресурсная база. Кто овладеет Debian'ом - тот овладеет рынком.

Лучшим техническим решением, по моему мнению, был бы upstart. Но лучшим политическим решением - раз и на всегда отказаться от затеи использовать в качестве важных системных составляющих наработки, полностью подконтрольные крупным коммерческим компаниям, в частности отказаться от использования systemd и upstart, а направить усилия на доработку классического init'a, или создать свой собственный велосипед. Вся надежда сейчас на Яна Джексона...

[Malaheenee]

Новость в тему: Ubuntu переходит на systemd следом за Debian

Марк Шаттлворт объявил о намерении перевести Ubuntu Linux на системный менеджер systemd. По словам Шаттлворта, как член семейства Debian проект Ubuntu поддержит решение технического комитета Debian по переходу на новую систему инициализации, даже если оно оказалось не в пользу детища компании Canonical.
[...]
Сроки перевода Ubuntu на systemd пока не оглашены, скорее всего миграция будет завершена и стабилизирована к LTS-выпуску 16.04 или 18.04, в зависимости от готовности версии Debian с systemd. Начальная поддержка использования systemd в качестве опции в Ubuntu ожидается вскоре после появления стабильной поддержки systemd в Debian.
[...]
Для пользователей миграций пройдёт предельно прозрачно. С точки зрения стратегии, миграция Debian и Ubuntu позволит рассматривать systemd как новый единый стандарт для Linux-систем

Открыть содержимое (спойлер)

Слили Upstart, в общем...

[свернуть]

[Brainey]

Открыть содержимое (спойлер)

Скорее, облегчили себе жизнь. Rhel переходит на systemd, Debian, возможно, тоже. Ну не самим же upstart поддерживать? 

[свернуть]

[vladimir_ar]

А я уже немного в systemd освоился  Тем более, лично мне он понятнее (учитывая, что и sysvinit не особо знал).
Сообщение объединено: 15 Февраль 2014, 11:00:54
Новость старая, но по теме
Принято решение о слиянии проектов udev и systemd
Сообщение объединено: 15 февраля 2014, 16:13:07
Неплохая книга по systemd
systemd для администраторов

[sunny_side]

Еще одна практичная точка зрения на systemd,
а также "критика на критику" systemd и одно из лучших обозрений sys v init.
Статьи довольно "многословные" но интересные.

[gardarea51]

Блин, а этот John Mist очень таки дельно говорит. Мне systemd в принципе понравился.. но так почитаешь и даа.. реально в нестандартных условиях люди будут нарываться на проблемы.

[sandaksatru]

одно из лучших обозрений sys v init.

Не могу полностью согласиться. Параллельная загрузка уже реализована, я сейчас визуально не замечаю особой разницы между системами по времени при запуске. Вообще systemd и классический system v init - две разные философии. И плюсы одной системы в рамках противоположной философии являются наоборот недостатками. Самое главное, чтобы никто не навязывал свою философию и не ограничивал свободу других.

[Brainey]

Имхо, не нужно торопиться, нужно посидеть, подождать и посмотреть, с какими проблемами столкнуться уже перешедшие дистрибутивы, а уже потом принять решение.

[Malaheenee]

Желтовато, но пусть будет:

Инженер SUSE, Neil Brown написал пару статей, где попытался описать свой опыт с systemd, как upstream-мэйнтейнера mdadm и nfs-utils.
Для начала Neil отмечает, что init-скрипты слишком сильно отличаются от дистрибутива к дистрибутиву, чтоб имело смысл их поставлять в составе файлов в upstream. Да и для сложных случаев, таких, как nfs-utils, синхронизация с помощью SysV была недостаточной, и Neil затрудняется вспомнить, есть ли дистрибутив, в котором демоны NFS для сложных конфигураций были бы запущены в нужном порядке. А вот в случае с systemd, это стало возможным - и общая настройка для всех дистров, и точный порядок запуска.
Neil увидел уменьшение объема скриптов systemd по сравнению с SysV (примерно с 800 строк до менее 200 строк), зато ему пришлось включить большее количество описаний сервисов - вместо двух SysV-скриптов, для nfs-utils понадобилось 14 systemd-файлов. К счастью среди этих 14 файлов присутствуют 4 *.target (в терминологии systemd, это некая "точка" на дереве загрузки системы, достигнутая стадия), что упрощает жизнь пользователей.
Дальше Neil заинтересовался, как бы не дать повода пользователю редактировать unit-файлы, одновременно позволив ему изменять ряд параметров (количество потоков демона и т.п.). Тут Neil увидел область, нуждающуюся доработки. Например, если пользователь хочет переназначить порт, то было бы логично просто установить переменную $MOUNTD_PORT где-нибудь в /etc/sysconfig/<appname> или /etc/defaults/<appname>. Однако, тогда демону может потребоваться ключ командной строки, который не нужен, если порт не переназначается. Т.е. требуется написать что-то типа

/usr/sbin/rpc.mountd ${MOUNTD_PORT:+-p $MOUNTD_PORT}

(если установлена переменная, то добавить ключ командной строки, иначе не добавлять). В systemd возможности задавать такие условия нет, и пользователю придется пересоздавать unit-файл в /etc/systemd. А это "перезапишет" изменения в unit-файлы из /usr/lib/systemd. Можно, конечно, указывать в файлах конфигурации не $MOUNTD_PORT, а  MOUNTD_PORT_ARG="-p 12345", но это как-то не очень красиво получается. Вообще, более правильно было бы использовать include-директивы или "drop-ins" (unit-файлы в директории /etc/systemd/system/*.d).
Neil продолжилвторую часть с обсуждения вопросы активации сервисов. Он отмечает, что в отличие от Upstart, установка unit-файла не означает его автоматическую активацию. Далее он обращает наше внимание на существенную разницу в активации legacy-сервисов из SysV, с помощью insserv, и в systemd. В SysV активация сервиса сопровождается проверкой на завивимости (директива Required-Start), и если сервис не активирован, но insserv выпадает с подробным сообщением, из которого понятно. что нужно сделать. Утилита для обработки SysV-скриптов из systemd действует по-другому - оно учитывает порядок, но не смотрит на наличие. Таким образом можно смело говорить, что работать SysV-скрипты в systemd будут лишь в простейших случаях, и потребуется полный переход на него.
Neil также отмечает, что несмотря на противопоставление event-based системе активации из Upstart и декларативному подходу в systemd, некоторые сервисы активируются таким образом, что сторонний непредвзятый наблюдатель не сможет отличить это от событийной модели активации. Например, mdadm активируется с помощью udev, при появлении дискового массива - это выглядит именно как событие.
Дальше Neil обращает внимание на недоработку - в механизме socket activation отсутствует возможность активации не с предопределенного, а с произвольного номера порта. Это нужно для rpc.statd. Что интересно, в Solaris такой механизм есть.
Возвращаясь к параллелям и отличиям с Upstart, Neil продолжает анализировать активацию сервисов и отмечает, что достижение target в systemd хотя и практически неотличимо от событий Upstart ("starting"), сервисы systemd запускаются не по событиям, а сами создают списки событий ("я запускаюсь, поэтому запусти также то-то и то-то"). Зависимость тут развернутая - сервис Upstart точно знает, что за событие его запустило, в то время, как сервис systemd знает какие "события" (сервисы) оно запускает. Здесь очень интересно появление двух директив в systemd WantedBy и RequiredBy, которые являются антиподами для Wants и Requires соответственно, но в отличие от них могут использоваться лишь в секции [Install]. Эти директивы можно считать аналогом "start on" в Upstart, но интересно, что в секции [Unit] их использовать не получится. Несмотря на то, что каждое указание Wants и Requires в секции [Unit] действительно создает внутреннее представление WantedBy и RequiredBy в зависимых сервисах, явное их использование не допускается.
Neil продолжает с интересной задачей - условный запуск сервиса (запускать лишь в каком-то случае, иначе запускать другой сервис). Оказалось, что без вмешательства суперпользователя это в общем случае нерешимо. Однако, в ряде случаев, используя директиву Requisite=, удалось привязать сервис к доступности указанного target. Сервис не запускается, если не запущен target, и останавливается сразу при остановке target. Получив уже четыре разных target в составе пакета nfs-utils, Neil отмечает удобство пресетов (presets) для systemd, которые позволяют мэйнтейнерам дистрибутивов самостоятельно решать то, какие target и сервисы будут включены по умолчанию.
Подытоживая вопросы активации, Neil говорит, что systemd предоставляет довольно богатый набор директив для управления сервисами, которые покрывают даже очень сложные случаи. К сожалению, как отмечает Neil, включение и отключение сервисов не принимает во внимание файлы конфигураций из /etc/sysconfig или /etc/defaults. Также интересно, что поведение udev по запуску правил по умолчанию полностью отличается от systemd, хотя присутствует в том же пакете ПО.
Далее Neil, обладая некоторым опытом разработки языков программирования, переключается с практических аспектов, на теоретические. Он недоумевает - директивы systemd разрешены лишь в конкретных секциях, тогда зачем нужны все эти [Unit], [Service], [Install]? Ну, кроме того, чтоб unit-файл выглядет бы как ini-файл.
Neil продолжает с логическими директивами systemd, такими как ConditionPathExists, которые отчасти позволяют логические выражения, такие, как A and B and (C or D or E), но не такие, как (A or B) and (C or D). Он интересуется, почему было бы не использовать традиционные правила, вместо частичного их подмножества. Любое отклонение от общепринятого стандарта лишь усложняет изучение, хотя и понятно, что сложные логические выражения в unit-файлах не будут часто встречаться. Однако, собственная алгебра логики, это не единственное проблематичное место. Neil отмечает огромное количество директив - Requires, RequiresOverridable, Requisite, RequisiteOverridable, Wants, BindsTo, PartOf, Conflicts, Before, After, OnFailure, PropagateReloadsTo, ReloadPropagateFrom и т.п. Он чувствует, что такое их количество, это явный признак некоей модели, скрытой от пользователя, и которую можно было бы более эффективно представлять с помощью DSL.
На этом Neil останавливается, и подводит итог. Он отмечает. что указанные менее 200 строк он написал с первой попытки, и он впервые чувствует, что его описание nfs-utils в systemd делает именно то, что нужно. Как разработчик, он отмечает, что наконец-то он обладает инструментарием и языков описания, которое позволяет ему выражать именно то, что он хочет, и сравнивая с тем, что дает разработчикам systemd, можно не обращать внимание на в основном косметические минусы.

[programmist11180]

https://www.linux.org.ru/news/opensource/10195930
В systemd уже пихают функции сетевого менеджера и пакетника.
Чисто как система инициализации systemd хорош, но запихивание в него совершенно посторонних вещей портит всё.

[yura_n]

Может быть я параноик, но меня настораживает не качество systemd, а те, кто его внедряет и как они это делают. Сначала пытались внедрить pulseaudio, но многие юзеры его не приняли и просто удаляют оный пакет. Начали внедрять systemd, который рядовой юзер уже ни за что не выпилит со своего компьютера.  А теперь понемногу оказывается, что systemd пытается заменить собой еще и ряд основных служб. То есть, на мой взгляд, происходит явная попытка "приватизировать" часть системы. Что будет, когда это произойдет? Почему-то я в альтруизм крупных корпораций не верю.