История изменений

О какой альтернативной реализации идет речь? Простая обманка, еще меньше 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. Отсутствие нормального тестирования.

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

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

О какой альтернативной реализации идет речь? Простая обманка, еще меньше 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.» Вкратце — FOSS и vendor lock-in являются взаимоисключающими понятиями.

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

Идиотизмы

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

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

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

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

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

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

О какой альтернативной реализации идет речь? Простая обманка, еще меньше 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.» Вкратце — FOSS и vendor lock-in являются взаимоисключающими понятиями.

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

Идиотизмы

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

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

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

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

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