systemd с разных точек зрения

Строго говоря, это не проблема бинарных логов, а несовершенство консольного интерфейса systemd: для этого нет удобной команды.

Я бы сделал такие обертки на шелле:

function systemctl-start() {
    systemctl start "$@" || systemctl status "$@"
}

function systemctl-start-watch() {
    systemctl start --no-block "$1"
    journalctl -f _SYSTEMD_UNIT="$1"
}

Это уже что-то. Спасибо!

Можно, конечно, и радикально: попросить systemd направлять stdout/stderr процессов не в лог, а в консоль. Насколько помню (машины нет под рукой), в system.conf для этого есть настройка.

А так и есть. journalctl -D /mnt/rescue/var/log/journal, и никакого запущенного systemd, уверяю, не требуется.

А если система ВООБЩЕ упала? Крах файловой? Текст можно вытащить хотя бы частично, а бинари? Один бит того, и все, приехали.

Пруфы?

В Арче и Зюзе обещали, что systemd будет опциональным. И что? В следующих же выпусках он стал безальтернативным.

Обещали модульность. А потом жестко завязали на него udev и гном.

И вообще, где, мать вашу, roadmap проекта??? План развития, цели разработки? Какой-то контроль качества? Типа серьезная разработка, а выглядит студенческой поделкой - Леня воротит что ему голоса в голове подскажут, совершенно не заботясь о последствиях.

Текст можно вытащить хотя бы частично, а бинари? Один бит того, и все, приехали.

Восстановление из повреждённых файлов там есть (прозрачное). Повреждённые записи пропускаются.

В Арче и Зюзе обещали, что systemd будет опциональным.

Насчёт суси не знаю (пруфы, пруфы), а вот в арче ни разу не обещали. Точнее, в каком-то смысле он до сих пор опционален: берёшь и выпиливаешь, вместе со всем, что от него зависит.

Обещали модульность. А потом жестко завязали на него udev и гном.

А при чём тут модульность? Модульность — это когда можно заменить реализацию какого-то из компонентов (сохраняя API и/или ABI-совместимость). И это, я тебя уверяю, возможно. Недаром в каком-то из BSD в рамках GSoC будут писать альтернативную реализацию logind, timedated, hostnamed и ещё чего-то.

Вообще, я наблюдаю лицемерие. Почему любая другая зависимость, например, firefox от gtk2, — это норм, а вот зависимость чего-то от systemd вызывает предельное возмущение?

roadmap проекта

Нет его, а зачем?

цели разработки

«systemd is a system and service manager»

совершенно не заботясь о последствиях

О каких последствиях?

Почему любая другая зависимость, например, firefox от gtk2, — это норм, а вот зависимость чего-то от systemd вызывает предельное возмущение?

Мастер аналогий 80 уровня. Ещё сравни это с тем, как firefox от C++ зависит.

А что не так?

firefox линкуется с gtk2, используя ряд его API.

polkit связывается с logind по шине, используя ряд его API. ($рандомный_проект_завязанный_на_systemd делает то же самое.)

Второй случай даже мягче, потому что шинное API гораздо более абстрактно, чем сишное API gtk2.

Восстановление из повреждённых файлов там есть (прозрачное). Повреждённые записи пропускаются.

Млять, ты хоть раз пробовал вытягивать данные из рухнувшей файловой системы? Явно нет, иначе бы такого бреда не гнал. Иногда единственная надежда это ГЛАЗАМИ найти кусок текста, что в случае с бинарниками очевидно невозможно.

Модульность — это когда можно заменить реализацию какого-то из компонентов (сохраняя API и/или ABI-совместимость). И это, я тебя уверяю, возможно.

Даааа? И как мне заменить, например, systemd-udev или logind на альтернативную реализацию?

Недаром в каком-то из BSD в рамках GSoC будут писать альтернативную реализацию logind, timedated, hostnamed и ещё чего-то.

Это не альтернативная реализация, а костыли типа wine, чтобы гном хоть как-то запускался. Так и винду можно модульной назвать.

Почему любая другая зависимость, например, firefox от gtk2, — это норм, а вот зависимость чего-то от systemd вызывает предельное возмущение?

Firefox ИЗНАЧАЛЬНО писался на gtk, а вот udev раньше никакого отношения к systemd не имел. И его завязывание очень похоже на методы грязной конкуренции.

Нет его, а зачем?

«systemd is a system and service manager»

Поколение пепси, как и Поцтеринг, собственно. Чтобы знать, чего ожидать в будущем. А то регулярно шокирующие новости от агентства «Голоса в голове Лени».

Блин, и тянул кто-то космонавта за язык...

А если система ВООБЩЕ упала? Крах файловой? Текст можно вытащить хотя бы частично, а бинари? Один бит того, и все, приехали.

Если информация может потеряться из-за проблем с файловой системой — она не нужна. Иначе кто-нибудь давно бы подумал о резервировании.

Иногда единственная надежда это ГЛАЗАМИ найти кусок текста

Если это — твоя единственная надежда, ты что-то делаешь не так (ц). Совсем. Для настолько неприоритетных юзкейсов есть перенаправление в syslog.

Даааа? И как мне заменить, например, systemd-udev или logind на альтернативную реализацию?

Очень просто. Пишешь альтернативную реализацию, совместимую по шинному API, и (если по-простому) подменяешь /usr/lib/systemd/systemd-{udevd,logind}.

Это не альтернативная реализация, а костыли типа wine

4.2. Не говорил бы хоть, если не знаешь. «Костыль типа wine» — это эмуляция API ядра Linux. Вообще, смотри сам: https://www.google-melange.com/gsoc/project/details/google/gsoc2014/kremlin/5... — это именно альтернативная реализация.

И его завязывание очень похоже на методы грязной конкуренции.

Что, Поттеринг опять ночью пришёл к мейнтейнерам с 12GA и потребовал передать ему управление проектом? И лицензию поменять, чтобы форкнуть было невозможно.

Впрочем, уже форкнули, так что ты точно не прав. Что-то у них плохо дело идёт, я смотрю.

Поколение пепси

Да, а ты прямо феерический «олдфаг».

это было? https://plus.google.com/104257421720370350735/posts/KBJGKUg3AnT

Если это — твоя единственная надежда, ты что-то делаешь не так (ц). Совсем.

Ты таки теоретик, который никогда не работал на производстве. И никогда не слышал слов «форс-мажор». А мне, знаешь ли, приходилось поднимать сервера и вытягивать информацию. Так что поверь моему опыту - бинарные логи полный отстой.

Для настолько неприоритетных юзкейсов есть перенаправление в syslog.

Ну я и говорю - проблемы с systemd решаются выпиливанием systemd.

Не говорил бы хоть, если не знаешь. «Костыль типа wine» — это эмуляция API ядра Linux.

Ты хочешь сказать, что в OpenBSD появятся systemd юниты и бинарные логи? Вместе с QR-кодами и установкой софта на BTRFS разделы?

Что, Поттеринг опять ночью пришёл к мейнтейнерам с 12GA и потребовал передать ему управление проектом?

Насколько я помню, авторы udev в основном сотрудники RedHat. Дальше все просто, с начальством не спорят. Леня ведь любовница кого-то из руководства, а чего не сделаешь ради любимой.

Впрочем, уже форкнули, так что ты точно не прав. Что-то у них плохо дело идёт, я смотрю.

Здесь Леня просто оказался бессилен, GPL, знаешь ли.

Ты таки теоретик, который никогда не работал на производстве. И никогда не слышал слов «форс-мажор».

Не нужно быть практиком, чтобы понимать — описанная тобой ситуация называется не «форс-мажор», а «факап».

Ну я и говорю - проблемы с systemd решаются выпиливанием systemd.

Проблемы с чем угодно решаются, в частности, выпиливанием. Но это твоё высказывание здесь нерелевантно. Если тебе по каким-то причинам не нравится хранение логов с помощью journald (но их «бинарность» — ещё раз, не причина) — можно отключить хранение логов с помощью journald.

В общем, хранение логов в бинарном файле не является «проблемой, неизбежно возникающей при применении systemd», так что твой аргумент неверен.

Ты хочешь сказать, что в OpenBSD появятся systemd юниты и бинарные логи? Вместе с QR-кодами и установкой софта на BTRFS разделы?

Нет. Я такого не говорил. Появится альтернативная реализация шинных API systemd. Кстати, ты противоречишь сам себе — именно «костыли типа wine» означали бы, что на OpenBSD запустят полноценный systemd через слой совместимости уровня ядра.

Здесь Леня просто оказался бессилен, GPL, знаешь ли.

Если это предположение о том, что «изменил бы, если бы было можно» — то оно совершенно беспочвенно и потому также не является корректным аргументом.

Не нужно быть практиком, чтобы понимать — описанная тобой ситуация называется не «форс-мажор», а «факап».

Факапы, знаешь ли, тоже бывают, причем несколько чаще, чем обычно считается. И остаться без инструмента последней надежды... не очень разумно.

но их «бинарность» — ещё раз, не причина

Кстати, я что-то не видел ни одного аргумента ЗА бинарность. Да, к этому можно приспособиться, и т.д., но ЗАЧЕМ? В чем профит?

можно отключить хранение логов с помощью journald.

Угу. Если из systemd отключить все идиотизмы, то от него мало что останется. И нафига тогда им вообще пользоваться? Системы без идиотизмов и так существуют.

Появится альтернативная реализация шинных API systemd

Кстати, ты противоречишь сам себе — именно «костыли типа wine» означали бы, что на OpenBSD запустят полноценный systemd через слой совместимости уровня ядра.

Ты вообще понимаешь, что собой представляет wine? Срочно учить матчасть дабы не позориться. А еще себя программистом себя называл, лол. У вас в systemd все такие? Тогда не удивительно, да.

Если это предположение о том, что «изменил бы, если бы было можно» — то оно совершенно беспочвенно и потому также не является корректным аргументом.

Ты, кстати, в курсе, как появился systemd? Когда Шапка в очередной раз обвинила Каноникал в том, что они нихера не делают, а только пиарятся, то Шатлврот возьми и ляпни - «Мы написали upstart, а вы им пользуетесь!». В результате прогерам Шапки было дано задание в кратчайшие сроки написать что угодно, только не upstart. Разумеется, это поручили Лене, как любимой жене. Ну и, собственно, имеем что имеем.

Кстати, я что-то не видел ни одного аргумента ЗА бинарность.

Индексация.

Если из systemd отключить все идиотизмы, то от него мало что останется.

В студию реквестируется перечисление «идиотизмов» с корректным указанием причины того, почему это идиотизмы. Иначе — необоснованное утверждение.

Ты вообще понимаешь, что собой представляет wine?

Прекрасно представляю. Это загрузчик PE плюс реимплементация API ядра плюс реимплементация некоторого набора виндовых либ (т. е. в совокупности — реимплементация Win32 API).

Так вот, «костыли типа wine» — это если бы в юзерспейсе BSD проэмулировали ряд API ядра Linux и поверх этого запустили бы оригинальный systemd. А имеется, напротив, реимплементация API systemd.

Ты, кстати, в курсе, как появился systemd? <...>

А вот здесь написано, что ты не прав. И не нужно говорить, что, мол, там враки — точнее, если будешь так говорить, потрудись предоставить пруфы (а не собственное или чьё-либо ещё вангование).

Индексация.

Мелочь. Не перевешивает недостатков.

В студию реквестируется перечисление «идиотизмов» с корректным указанием причины того, почему это идиотизмы. Иначе — необоснованное утверждение.

Млять. Я уже сколько распинаюсь именно об этом. Перечитай ветку.

Так вот, «костыли типа wine» — это если бы в юзерспейсе BSD проэмулировали ряд API ядра Linux и поверх этого запустили бы оригинальный systemd.

То есть wine это прослойка, позволяющая запустить оригинальное ядро винды в пространстве линукса???

Таки лол. Вся комманда systemd дружно отправляется в психушку.

А вот здесь написано, что ты не прав.

Слишком гладко и красиво написано. В жизни обычно бывает несколько по-другому.

Не перевешивает недостатков.

Млять. Я уже сколько распинаюсь именно об этом. Перечитай ветку.

Ещё раз, ты не привёл ни одного валидного недостатка ни journald, ни systemd. Невозможность восстановления бинарного файла путём чтения глазами — не недостаток, т. к. сама необходимость в таком восстановлении означает, что админ неправильно организовал работу системы, оставив экспериментальную/нестабильную ФС без бэкапа.

То есть wine это прослойка, позволяющая запустить оригинальное ядро винды в пространстве линукса???

Ещё раз, для особо умных. Wine эмулирует API винды, позволяя запускать оригинальные виндовые приложения в другой ОС. Гипотетический «костыль типа wine» тогда должен эмулировать API линукса (ядра Linux), позволяя запускать оригинальные линуксовые приложения (systemd) в другой ОС (*BSD).

Таким образом, альтернативная реализация API systemd для *BSD — это

• не «костыль типа wine» (т. к. не эмулирует API ядра другой ОС);
• не приведёт к тому, что «в OpenBSD появятся systemd юниты и бинарные логи» (т. к. не является портом самого systemd на другое ядро).

Слишком гладко и красиво написано. В жизни обычно бывает несколько по-другому.

Я же сказал — без вангования, только факты.

В общем, если кто и слил, так это ты. Ты на протяжении более пяти постов не привёл ни одного практического недостатка systemd (тем более ни одного неисправимого-фатального) и запутался в своих же словах на тему альтернативной реализации API systemd. Разговор можно считать оконченным.

бэкапа

Ты дурак? Речь идет не о данных, а о логах в момент, непосредственно предшествующий факапу. Например, у нас настроен ежедневный бэкап, но интересны события за несколько секунд перед падением ФС. Как здесь поможет бэкап???

Или это условный рефлекс - слышим «факап», сразу отвечаем «бэкап» и чувствуем себя охренеть предусмотрительными, в отличие от этих ламеров?

Короче, внятного решения нет, значит systemd не готов для mission-critical application.

Wine эмулирует API винды, позволяя запускать оригинальные виндовые приложения в другой ОС. Гипотетический «костыль типа wine» тогда должен эмулировать API линукса (ядра Linux), позволяя запускать оригинальные линуксовые приложения (systemd) в другой ОС (*BSD).

не приведёт к тому, что «в OpenBSD появятся systemd юниты и бинарные логи» (т. к. не является портом самого systemd на другое ядро).

А мальчику не приходило в голову, что имитация API возможна не только ядра, но и любого другого API? А ведь стоит обдумать такую простую мысль и сразу становится ясно, что он сам не понимает, о чем говорит. BSDшники пилят имитацию API systemd, которая будет обманывать Гном так же, как wine обманывает виндовые приложения.

Ты на протяжении более пяти постов не привёл ни одного практического недостатка systemd

Бремя доказательства лежит на утверждающем (с). Поцтеринг сотоварищи пришли на вполне устоявшийся рынок со своим продуктом. Именно они должны предъявить его преимущества перед существующими, иначе не понятно, зачем их продукт нужен. И вот что-то таковых преимуществ не наблюдается. Одно время вопили о скорости загрузки, но на практике вышел фейл - Гента с OpenRC грузится быстрее Федоры с systemd, а Pisi Linux еще быстрее. А вот других преимуществ как-то не наблюдается. Или о них не говорят. Сторонники systemd обычно просто начинают оскорблять оппонентов и переходить на личности.

Окей, отвечу.

Речь идет не о данных, а о логах в момент, непосредственно предшествующий факапу.

Значит, включается передача логов по сети. Она там есть. А если её не хватает — включается syslog-совместимость, которая там есть вполне намеренно (но не с описанной тобой целью, а потому что связка rsyslog+logrotate гибче в плане настройки хранения и ротации).

имитация API возможна не только ядра, но и любого другого API

Имитация возможна только того API, для которого не предусматриваются альтернативные реализации. Имитация — это, грубо говоря, bug-to-bug quirk-to-quirk compatibility. Так что ты определённо мимо с этим утверждением.

Бремя доказательства лежит на утверждающем

...на утверждающем кривоту systemd. Всё именно так. Ты же ничего не доказал, а сразу же перешёл на те самые личности. Заметь, я на личности не переходил и тебя не оскорблял (в отличие от).

Именно они должны предъявить его преимущества перед существующими, иначе не понятно, зачем их продукт нужен.

Никому они ничего не должны. Если их «продукт» используют (а его будут использовать теперь уже и KDEшники, которые редхату точно ничего не должны) — значит, преимущества есть. Всё просто.

Одно время вопили о скорости загрузки, но на практике вышел фейл - Гента с OpenRC грузится быстрее Федоры с systemd, а Pisi Linux еще быстрее.

Пруфы, пожалуйста. Я наблюдаю обратное.

связка rsyslog+logrotate гибче в плане настройки хранения и ротации

Вот с того надо было начинать. То есть логи в systemd хуже и вы сами это понимаете, но продолжаете проталкивать свою кривую поделку? Супер.

Имитация возможна только того API, для которого не предусматриваются альтернативные реализации.

Сам понял, что сказал? По самой своей сути имитация возможна чего угодно, независимо ни от чего. Вот что мне мешает написать свою имитацию видового API, отличную от wine? Кстати, имитаций API DOS существует минимум две - dosbox и dosemu. Так что разупорись.

...на утверждающем кривоту systemd. Всё именно так.

Любой продукт, который выходит на занятый рынок, априори считается кривым и ненужным, пока не докажет обратное. Вот и доказывай.

Никому они ничего не должны. Если их «продукт» используют (а его будут использовать теперь уже и KDEшники, которые редхату точно ничего не должны) — значит, преимущества есть. Всё просто.

Пиар, административный ресурс Шапки и «голубая солидарность»(пидарасы всегда поддерживают других пидарасов). Кстати, насчет KDE злостное 4.2 - о завязке на systemd заявил, только заявил, один разработчик и касалось заявление только KDE for Wayland, который сам по себе не особо нужен. На иксовую версию никто не покушается. Так что не надо свои голубые мечты выдавать за реальность.

Вобщем, понятно. Никаких преимуществ у systemd нет, есть NIH синдром, конкуренция RedHat и Canonical, «голубая солидарность» и истерика «поколения пепси», которые не хотят изучать существующие системы, а хотят сразу ваять шедевры. Напоминает Пол Пота, который совершил революцию в Камбодже, раздав школьникам(в прямом смысле) оружие и разрешив стрелять во взрослых.

Я наблюдаю обратное.

Ты осилил генту и ставил Pisi Linux? Свежо предание, но верится с трудом (с)

Никаких преимуществ у systemd нет, есть NIH синдром, конкуренция RedHat и Canonical, «голубая солидарность» и истерика «поколения пепси», которые не хотят изучать существующие системы, а хотят сразу ваять шедевры. Напоминает Пол Пота, который совершил революцию в Камбодже, раздав школьникам(в прямом смысле) оружие и разрешив стрелять во взрослых.

Интересно, а где учат такому словотворчеству? Прямо аж завидно.

То есть логи в systemd хуже и вы сами это понимаете, но продолжаете проталкивать свою кривую поделку? Супер.

Чем-то лучше, чем-то хуже. Для кого как. Никто не проталкивает Storage=persistent в journald.conf.

Сам понял, что сказал? По самой своей сути имитация возможна чего угодно, независимо ни от чего.

Имитация и правильная альтернативная реализация — идейно разные вещи.

Любой продукт, который выходит на занятый рынок, априори считается кривым и ненужным, пока не докажет обратное. Вот и доказывай.

Во-первых, нет. Только «ненужным». Нужность systemd постепенно доказывается, а о кривости вопить начал ты. Неаргументированно.

Пиар, административный ресурс Шапки и «голубая солидарность»

Пруфы или FUD.

о завязке на systemd заявил, только заявил, один разработчик и касалось заявление только KDE for Wayland

Тем не менее. А в рассылке кто-то из кедоразработчиков изъявил интерес в портировании на systemd --user.

который сам по себе не особо нужен

Не тебе решать.

NIH синдром, конкуренция RedHat и Canonical, «голубая солидарность» и истерика «поколения пепси»

Пруфы или FUD.

которые не хотят изучать существующие системы, а хотят сразу ваять шедевры

Лично я некоторое время держал на локалхосте каждую из систем инициализации «большой четвёрки» (openrc — в составе генту) и пришёл к выводу о безоговорочном превосходстве systemd по части удобства управления (а после запила туда некоторой фичи ещё и понял, что код збс). Так что мимо.

Ты осилил генту и ставил Pisi Linux?

Представь себе. И там нечего осиливать, всё тривиально.

пидарасы

голубые мечты

поколение пепси

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

Имитация и правильная альтернативная реализация — идейно разные вещи.

BSDшники собираются запилить не весь systemd, а тонкую прослойку, исключительно с целью обмануть Гном 3. О какой альтернативной реализации идет речь? Простая обманка, еще меньше wine.

Нужность systemd постепенно доказывается, а о кривости вопить начал ты. Неаргументированно.

Еще раз - рынок систем инициализации УЖЕ был насыщен. Тут появляется Поцтеринг со своим продуктом и хочет заменить ВСЕ остальные, причем вместо того, чтобы показать преимущества своего продукта, начинает давить админресурсом Шапки и использовать пятую колонну из психологически неустойчивых товарищей. Напоминает продвижение христианства, однако.

Лично я некоторое время держал на локалхосте каждую из систем инициализации «большой четвёрки» (openrc — в составе генту) и пришёл к выводу о безоговорочном превосходстве systemd по части удобства управления (а после запила туда некоторой фичи ещё и понял, что код збс). Так что мимо.

«Посоны, я тут такую крутую фишку нарыл, ее наш чувак запилил, он наплевал на все правила этих стариков, мы теперь им всем покажем!». С возрастом пройдет.

Представь себе. И там нечего осиливать, всё тривиально.

Ладно, допустим, что Генту осилил. Но Pisi Linux вряд-ли видел, а в вопросе скорости загрузки это событие. Впечатляет.

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

Ты хочешь сказать, что Поттеринг не гомосек? Дык у него на физиономии все нарисовано.

Ладно, я таки приведу список недостатков systemd. Специально для ослепленных:

1. Гибкость. В systemd можно сделать только то, что ЗАРАНЕЕ заложено. Нестандартные конфигурации в пролете. 2. Надежность. systemd становится единой точкой отказа - если он сглючил, то рушится все. 3. Сложность настройки. В попытках решить пункт 1 изначально простой формат конфигов превратился в что-то совсем наркоманское. 4. Предсказуемость. Никто не знает, что голоса подскажут Лене в следующий момент. 5. Нестабильное API. 6. Vendor lock-in. 7. Идиотизмы типа бинарных логов и разделов btrfs. 8. Агрессивное пропихивание везде куда можно и нельзя. 9. Отсутствие нормального тестирования.

И, запомни, если программа работает на компе разраба, то это еще не значит, что она будет работать у клиентов. Это первое правило коммерческого программиста, и пишется оно кровью :)

А что такого особенного?

А если система ВООБЩЕ упала? Крах файловой? Текст можно вытащить хотя бы частично, а бинари? Один бит того, и все, приехали.

А чем текст отличается от бинарей? Текст тоже в бинарном виде хранится же. Почему его можно восстановить, а журнал systemd нет?

О какой альтернативной реализации идет речь? Простая обманка, еще меньше wine.

I am writing four DBus daemons that accept systemd calls and emulate their behavior correctly.

Ты не прав.

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

Преимущества показаны по ссылке, приведённой выше (и ещё хреналион раз в рамках выбора инит-системы в Debian, см. баг 727708). Насчёт пятой колонны — подтверждение своим словам ты предоставлять, видимо, не собираешься.

Pisi Linux вряд-ли видел

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

1. Гибкость. В systemd можно сделать только то, что ЗАРАНЕЕ заложено. Нестандартные конфигурации в пролете.

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

2. Надежность. systemd становится единой точкой отказа - если он сглючил, то рушится все.

Отчасти справедливо. Если упал PID 1, то всё действительно плохо (впрочем, паники ядра даже в этом случае не будет). Но большинство кода systemd вне PID 1 — а остальные демоны умеют корректно и прозрачно перезапускаться.

3. Сложность настройки.

Субъективное понятие.

4. Предсказуемость. Никто не знает, что голоса подскажут Лене в следующий момент.

Необоснованное утверждение (FUD). Но даже если такое случится (и большинство разработчиков согласится в том, что systemd стал УГ) — неминуемо возникнет форк.

5. Нестабильное API.

Ложь.

6. Vendor lock-in.

«Because FOSS software can be modified and distributed by anyone, the availability of functionality cannot tie a user to one distributor.»

«As a result, software licensed under the GPL is especially resistant to vendor lock-in, since any individual or company that distributes original or modified versions of such software cannot legally prevent further modification and redistribution of the original source code.»

Вкратце — FOSS и vendor lock-in являются взаимоисключающими понятиями.

7. Идиотизмы типа бинарных логов и разделов btrfs.

Идиотизмы

Субъективное мнение.

8. Агрессивное пропихивание

Жду подтверждений.

9. Отсутствие нормального тестирования.

Автотесты есть, опровержение их пригодности — за тобой.

В общем, ни один из твоих аргументов не является валидным (часть — принципиально, часть — без пруфов). ЧТД.

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

emulate

Кто не прав?

Тебе просто хочется думать, что BSDшники портируют systemd. Приятно, наверно. И ради этого игнорируется все.

Преимущества показаны по ссылке, приведённой выше (и ещё хреналион раз в рамках выбора инит-системы в Debian, см. баг 727708).

Ты лично пока НИ ОДНОГО преимущества не привел. Вот возьми и приведи, без посылов в гугл и другие места.

Насчёт пятой колонны — подтверждение своим словам ты предоставлять, видимо, не собираешься.

Голосование по поводу дефолтной системы инициализации в Дебиян. Целый шпионский роман, мля.

Видел. Впрочем, бенчмарки приводить не буду

Слив защитан.

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

Пойди поработай в ынтерпрайз, там такого насмотришься... И, главное, никто не будет слушать твои оправдания, что данную систему надо выбросить, так systemd ее не поддерживает. Выбросят тебя, а не систему.

Ну например, /usr на отдельном разделе. Нужно для разделения изменяемых и неизменяемых данных, безопасность.

Если упал PID 1, то всё действительно плохо

В классическом ините в PID 1 кода намного меньше, чем в systemd. Дальше понятно?

Субъективное понятие.

Упоминаемая тобой легкость конфиругации systemd тоже весьма субъективна.

Необоснованное утверждение (FUD).

Леня это уже не раз демонстрировал, так что не надо ля-ля.

неминуемо возникнет форк.

А вот это сильно вряд-ли, так как кроме банальных друзей Лени, systemd никому не нужен.

Автотесты есть, опровержение их пригодности — за тобой.

А почему оно тогда так глючит?