Arch без Systemd (опыт)

Я как пример написал Slim - у него начались проблемы, когда логин в систему притянули в systemd как logind. И разработчики дропнули его, т.к. не стали переделывать свою работу под другого, потому что они (разработчики системд) решили сделать свои собственные интерфейсы

А что, по-твоему, должно было произойти? Свои собственные интерфейсы (logind) были придуманы не от нечего делать, а от несовершенства имеющихся. Если разработчики slim решили, что не их это барское дело — переписывать свой проект под изменившиеся, то это исключительно их проблемы.

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

Что-то все молчат как партизаны.

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

Кстати, как на счет upstart, System V init (в куче с ininng): их тоже выбросить?

Их выбросить в первую очередь.

Твой комментарий в стиле «Всё врёти! Нету никаких плюсов у systemd а те что есть вообще не нужны!». Эти плюсы были разжёваны уже кучу раз, тебе лишь нужно осилить прочитать.

И, да, grub1, grub2, lilо и иже с ними почему-то поддерживаются параллельно

grub1 ещё кто-то поддерживает? В прочем, есть всякие ретрограды — форкают и/или поддерживают то, что давно пора закопать.

Можно еще по-холливорить на тему bash vs zsh .

Зачем?

upstart

Его и так в убунте новой, ЕМНИП, выбросили.

System V init

Конечно выбросить.

А для кого-то есть? Что-то все молчат как партизаны.

Ну вот для меня, например, есть.

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

Не-е-ет, я считаю, что должно быть много программ, хороших и разных. И когда система проектируется - ее стоит делать так, чтобы не порушить как можно больше из того, что было раньше. Slim же был очень популярным DM до его скоропостижной кончины.

а от несовершенства имеющихся.

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

Его и так в убунте новой, ЕМНИП, выбросили.

Вроде еще с 15й...

sudopacman

Эти плюсы были разжёваны уже кучу раз

intelfx

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

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

Вот то, что я уже слышал:
1. Бинарные логи - на локалхосте штука бесполезная, а по мне еще и скорее вредная, но ладно.
2. Ускоренная загрузка - вообще не интересно по многим причинам.
3. Автоматический перезапуск процессов - штука однозначно вредная, так как если процесс упал, на то есть причина, и перезапуск его без устранения причины почти наверняка приведет к очередному падению
4. Запуск сервисов по требованию - тоже не интересно, ибо скорее добавит тормозов.

Дабы не плодить флейм, плюсы/минусы вышесказанного не обсуждаем. Просто приписываем эти фичи systemd и всё. Мне интересно что есть ещё, что, по твоему мнению, должно сподвигнуть юзера (именно юзера) поставить systemd. Кейс: человек ставит дистр на домашний комп (enterprise не рассматриваем), и хочет принять решение решение: systemd vs что-то другое.

Я весь внимание.

На случай, если не получилось скастовать: Arch без Systemd (опыт) (комментарий)

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

Ты серьёзно не видишь различий между несколькими инитами и несколькими тулкитами?

Его и так в убунте новой, ЕМНИП, выбросили.

Вранье! В репах есть. Пишу с 16.04 без системг ;)

Различий не видит Akutenshi (вот здесь). Я лишь продолжил его аналогию и показал, что она приводит к заведомо абсурдным выводам.

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

Для начала мы определимся, о каком конкретно интерфейсе мы говорим. Я говорю за logind: прочих вспомогательных *d ранее просто не было, а «интерфейс» к непосредственно иниту в лучшем случае был представлен одной командой /sbin/service, а в худшем вообще был дистроспецифичен; тут должно быть самоочевидно, чем systemd лучше: тем, что он а) универсален и б) супервизор, а не «моя хата с краю, я просто скрипты пускаю».

Так вот, logind. Самое его яркое отличие от ConsoleKit (в плане API) — в том, что logind больше похож на мандатное управление доступом (MAC), а CK — на дискреционное (DAC). А именно, в CK назначение процесса сессии выполняется при помощи выдачи ему некоторой переменной окружения (всего лишь), в то время как в logind это делается посредством помещения процесса в контрольную группу. Понятно, что первое можно обойти, а второе нельзя. Также не понятно, как в первом случае подсчитывать процессы в сессии и следить за их жизненным циклом.

Вообще, ты утверждал следующее:

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

Очевидно, что это плохая аналогия, т.к. тулкиты, в отличие от систем инициализации, могут спокойно сосуществовать в рамках одной системы (хоть настраивать консистентный внешний вид и больно, но это уже другой вопрос), а systemd (как явление — «повальный переход») приводит к vendor lock-in. По-моему, тут есть причины для недовольства.

• man systemd.service | grep Restart
• man systemd.unit | grep StartLimit
• man systemd.unit | grep OnFailure

Если вкратце: условия для рестарта (exit-code, сигналы, таймауты запуска, ватчдог), время ожидания перед рестартом, ограничение на количество попыток за указанное время, действие при превышении (можно попросить ребутнуть систему или просто указать произвольный юнит через OnFailure=).

тулкиты, в отличие от систем инициализации, могут спокойно сосуществовать в рамках одной системы (хоть настраивать консистентный внешний вид и больно, но это уже другой вопрос), а systemd (как явление — «повальный переход») приводит к vendor lock-in

Плевать. Требовать, чтобы прикладные программы, использующие удобный слой абстракции (logind), умели работать ещё и без оного — это настолько же абсурдно, как и требовать от программы на Qt или Gtk возможности работы без установленного в системе тулкита, поверх голых иксов.

$ man systemd.service
No manual entry for systemd.service

можно попросить ребутнуть систему или просто указать произвольный юнит через OnFailure=

Можно ли при этом перезагрузить сразу несколько юнитов? Пример, как _должно_ быть: OTP-шная иерархия супервизоров. Если крешится один воркер-процесс, супервизор перезапускает либо только этот воркер, либо все дочерние процессы. Если рестарты происходят слишком часто, то супервизор убивает все свои дочерние процессы и падает сам. Это падение замечает родительский супервизор, и т.д.

Внутренний стейт упавших процессов естественно уничтожается при этом.

Есть ли аналог супервизоров (или, если угодно, «групп процессов») в systemd?

Наверное, ещё более абсурдно было бы желать, например, чтобы программы, использующие уютный winapi, могли работать поверх голого POSIX? Или там вместо перформансного kqueue использовали что-то более переносимое.

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

Ясно — рестарт процессов игрушечный.

Остаюсь на древней, закрытой, проприетарной и доморощенной системе инициализации, которая это умеет делать правильно.

более абсурдно было бы желать, например, чтобы программы, использующие уютный winapi, могли работать поверх голого POSIX?

Конечно, а что, нет? Позикс — даже близко не замена винапи. Как ты гуевую программу перепишешь с винапи на позикс, если в позикс даже окошек нет? Вот так и с линуксом и системди: сигрупс, логинди и проч — наше все.

Очевидно же, использую один из зоопарка фреймворков. Да и вообще, можно подумать, в винапи одни окошки.

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

Смысл был в том, что хотеть переносимость часто довольно разумно

Ну если системди предоставляет определенные интерфейсы и все мажорные дистры сидят на системди, ориентация разработчиков очевидно. Линукс нынче — это системди.

Никто же не будет выкидывать всякие сигрупсы, потому что есть дебиан/кфрибзд, и там другое ядро?

Начнём с того, что в твоём комментарии аргументация уровня «шланг». Ты тупо отрицаешь все известные тебе плюсы systemd, а потом: «дабы не плодить флейм, плюсы/минусы вышесказанного не обсуждаем».

Мне интересно что есть ещё, что, по твоему мнению, должно сподвигнуть юзера (именно юзера) поставить systemd. Кейс: человек ставит дистр на домашний комп (enterprise не рассматриваем), и хочет принять решение решение: systemd vs что-то другое

В большинстве дистрибутивов это решение за него уже приняли разработчики (и правильно сделали). Так что вопрос надо задавать не «что должно сподвигнуть юзера поставить systemd?», а «что должно сподвигнуть юзера выпилить systemd[1]»?
[1] hint: тупость (либо весьма специфичный юзкейс).

Мне, конечно, лень всё это писать, но чтобы ты потом не возникал: «ну вот, они даже нормально объяснить не могут, чем этот их системдэ лучше», будет тебе ещё раз, специально для тебя.

Итак, systemd принёс упорядоченность в тот хаос из древних костылей, что был до этого в GNU/Linux, он лучше by design: удобные в написании юниты вместо глюченых простыней на баше; единый удобный и современный журнал, лишённый многих недостатков syslog (вот, почитай. аргумент «оно на десктопе не нужно» не принимается, о нём далее по тексту); единообразие и простота в написании юнитов для разных целей: теперь не нужно управляться с кучей разнообразных сущностей с отличающимся синтаксисом конфигов: вместо cron есть таймеры, монтировать разделы можно с помощью mount-юнитов, и т. д.; и множество других архитектурных улучшений (вроде параллельного запуска сервисов), которые можно тупо нагуглить, не вижу смысла описывать всё.

А теперь вернёмся к твоему — как я могу наблюдать — излюбленному аргументу «оно мне на локалхосте нинужно». Во-первых, не может быть не нужно то, что явно лучше того, что было. Если тебе предложат, например, Land Cruiser вместо «Уазика» (цена в данной аналогии не учитывается), то ты тоже будешь упираться и отнекиваться, мол «кому вообще нужна эта коробка-автомат»? А во-вторых, если уж и не нужно это на локалхосте, то не помрёшь ты, если оно у тебя появится. Тебе не станет хуже от того, что система начнёт загружаться быстрее, а логи станут занимать меньше места. Зато разработчикам станет проще, т. к. не придётся поддерживать весь зоопарк инитов. А не способные к обучению ретрограды своим нежеланием изучить новый инструмент лишь тормозят прогресс.

Если ты дочитал до этого предложения, а просветление до сих пор не наступило, перечитай моё сообщение ещё n раз, пока оно не наступит.

Запуск сервисов по требованию - тоже не интересно, ибо скорее добавит тормозов.

Добавит тормозов запуск всех сервисов, даже не нужных на данный момент, сразу на старте последовательно один за другим.

Во-первых, помимо линукса есть другие системы (заявления Поттеринга о том, что «поддержка совместимости с BSD замедляет развитие СПО», звучат, как по мне, абсурдно), а во-вторых — остались дистрибутивы без systemd из коробки — те же gentoo со слакой, например. Обычно говорят, что трудно поддерживать много инитов — но ведь в сколь-нибудь старых проектах поддержка классических init-скриптов давно была, а поддержка их, по большому счёту, сводится к тому, чтобы ничего не ломать.

Что касается фич вроде cgroups — да, в приложениях, где оно нужно и не нужна переносимость, их было бы странно выкидывать. Но такие юзкейсы на типичном десктопном линуксе редки, а systemd, тем не менее, прибивают гвоздями с огромным энтузиазмом.

использую Арч с SysV init, просто не перешел до сих пор и не вижу причин что-то менять сейчас. брат жив. тред не читал и не буду.

Kroz

Я дополню.

Во-первых, если человек ставит дистрибутив на домашний комп, то ему обычно нет никакой разницы, systemd там или что-то ещё. Ему важно, чтобы работало. Учитывая этот факт, можно сделать простой вывод: лучше тот софт, который лучше поддерживается.

Во-вторых, с этим связано ещё одно соображение (по поводу «мне не нужны advanced фичи»). Если тебя устраивает хардкод, то можно много чего выкинуть из системы. Можно вообще запускать всё одним скриптом на баше, как делают упоротые LFS'ники. Только в результате у тебя получится система, пригодная к использованию только лично тобой и на одном конкретном железе. Отсюда должно быть понятно, почему почти все дистрибутивы по умолчанию идут другим путём.

Это была философия. Теперь технически:

• [systemd] слежение за запущенными процессами, подчистка за всеми — например, если у тебя упадёт DE, то можно быть уверенным в том, что его ошмётки корректно прибьются;
• [systemd] авторестарт — и я не согласен с твоим несогласием, т. к. если где-то там случился рейс или какая-то программа насрала в heap и свалилась (что является наиболее частой причиной падения), то перезапуск вполне себе поможет.

  Опять же, если у меня, как пользователя, вдруг упал cups или bluetoothd, то меня меньше всего волнует то, что «для его падения есть причина, и авторестарт вреден, потому что её скрывает».

• [systemd] запуск по требованию — аналогично; зачем мне на ноутбуке постоянно запущенный cups, sshd или samba?
• [logind] мультисит, fast user switching — и нет, пользователь не должен уметь руками орудовать chown+chmod, чтобы подмонтировать флешку.
• [logind] SUID-less Xorg — туда же.

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

[systemd] запуск по требованию — аналогично; зачем мне на ноутбуке постоянно запущенный cups, sshd или samba?

А что до этого нельзя было так?

пользователь не должен уметь руками орудовать chown+chmod, чтобы подмонтировать флешку.

Ну хорош уже, года с 2008 так можно было.

Ну, когда я был молодой и глупый

А с этого момента точно что-то поменялось? (=

Ты забыл CPU_FLAGS_X86 и LTO.

Почему ты с таким подходом ещё не выпилил из системы Coreutils и bash? ImageMagick, ffmpeg не используешь, надеюсь?

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

с дублирующейся функциональностью

Нет, у них синтаксис разный. Слишком много скриптов завязано на bash и башизмы, чтобы от него отказываться.

Ну почему же? Самый первый заметный — ускоряется загрузка (иногда даже намного).

Во-первых, помимо линукса есть другие системы (заявления Поттеринга о том, что «поддержка совместимости с BSD замедляет развитие СПО», звучат, как по мне, абсурдно)

То есть по-твоему Red Hat должен тратить силы и время, чтобы поддерживать какую-то там полумёртвую бздю помимо своих дистров? Зачем?

Все правильно он говорит. Я напомню, что GNU — GNU's Not UNIX. Так с какого перепугу разработчики ещё должны заботиться о тех, кто считает себя идейными продолжателями UNIX и фукает при виде пингвинов и GNU?

То есть по-твоему Red Hat должен тратить силы и время, чтобы поддерживать какую-то там полумёртвую бздю помимо своих дистров?

Не должен, речь об общей тенденции, которая видится мне печальной

Я напомню, что GNU — GNU's Not UNIX.

А разве кто-то что-то говорил про GNU?

Да прекрати ты уже читать тред сверху вниз и отвечать на каждый комментарий.

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

Для Coreutils есть альтернатива — BusyBox. Про bash: есть dash, но не знаю, насколько он «не комбайн», ещё есть чистый sh. Касательно ImageMagick и ffmpeg мне лень сейчас искать, какие там у них альтернативы, можно просто не использовать пакеты, зависящие от них.

Нет, у них синтаксис разный. Слишком много скриптов завязано на bash и башизмы, чтобы от него отказываться

Зато и в bash, и в zsh, AFAIK, есть свои реализации некоторых Coreutils. Вот если бы bash мог только скрипты пускать, а zsh — быть интерактивной оболочкой, то было бы юниксвейно.

помимо линукса есть другие системы

И что теперь? Ну давай откажемся от линуксового апи, че, ведь под хайку и нетбзд компилировать надо. Равняются на лидера, пусть подтягивают свой слой совместимости.

остались дистрибутивы без systemd из коробки

Туда же. Если школьник вася запилит свой инит и дистрибутив с тремя пользователями, должны ли софтописатели на него ориентироваться? Если только они энтузиасты васиного дистрибутива разве что.

много инитов

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

десктопном линуксе редки

А вот логинд — нужная.

Да прекрати ты уже читать тред сверху вниз и отвечать на каждый комментарий.

Извини, комменты не ротирую по привычке.

есть альтернатива — BusyBox.

Ну да, давай вместо фирменного адидаса покупать подпольное Г с рынка.

Про bash: есть dash, но не знаю, насколько он «не комбайн», ещё есть чистый sh.

Авотфиг: башизмы типа [ ] глубоко вошли во многие скрипты и в головы многих.

Зато и в bash, и в zsh, AFAIK, есть свои реализации некоторых Coreutils.

Слабо относится к треду. %)

Зато и в bash, и в zsh, AFAIK, есть свои реализации некоторых Coreutils. Вот если бы bash мог только скрипты пускать, а zsh — быть интерактивной оболочкой, то было бы юниксвейно.

Оба они реализации интерпретаторов ЯП с REPL, не больше. Все их расширения различной степени упоротости это «стандартная библиотека».

Ну да, давай вместо фирменного адидаса покупать подпольное Г с рынка.

Зачем ты мне это всё объясняешь? Я-то не собираюсь bash выпиливать (хотя можно just for fun попробовать). А остальные иниты по сравнению с systemd и есть «подпольное Г с рынка».
Вникни в суть треда.

sudopacman, intelfx,

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

Начнём с того, что в твоём комментарии аргументация уровня «шланг».

Я и не пытался давать внятной аргументации, там скорее описано мое отношение. Я просто делю задачу на 1) перечень значимых фич 2) критика фич; по аналогии как это делается на brainstrom'ах.

1. Перечень

журнал ... вот, почитай

Хорошее описание. Зацепило «всё в одном месте вплоть до логов UEFI», OOB ротация с учетом свободного места. По крайней мее заменяет многие мои велосипеды.
Наверное, ечли бы его можно было установить отдельно, я бы над этим подумал.

[logind] мультисит, fast user switching

Кроме флешки - есть кейсы/описание? Погулю, конечно, но если есть ссылка на хорошее описание, дай пожалуйста.

[logind] SUID-less Xorg — туда же.

Как? Погуглю, но если есть ссылка на хорошее описание, дай пожалуйста.

2. Критика

излюбленному аргументу «оно мне на локалхосте нинужно»

Да, ибо важна именно практическая польза в конкретном кейсе, а не сферически кони в вакууме. Об этом многие забывают.

Во-первых, не может быть не нужно то, что явно лучше того, что было. Если тебе предложат, например, Land Cruiser вместо «Уазика» (цена в данной аналогии не учитывается), то ты тоже будешь упираться и отнекиваться, мол «кому вообще нужна эта коробка-автомат»?

Не буду.
А вот если мне предложат вертолет вместо машины - буду (для чистоты эксперимента - маленький вертолет с возможностью садиться на автомобильные стоянки). Хоть вертолет однозначно мобильней машины, им еще нужно научиться управлять. То есть имеется overhead, и пока на второй чаше весов не будет достпаточно бенефитов для моего кейса, я переходить на вертолет не буду.

а «что должно сподвигнуть юзера выпилить systemd[1]»

Если бы у меня стояла какая-то Убунта c уже впаянной systemd, то я бы принимал решение точно так же: весы, на одну чашу затраты по выпиливанию, на вторую - бенефиты. И, да, скорее всего я бы не выпиливал. Я привык мыслить рационально. Но у меня другая ситуация: Gentoo, и я сам на этапе установки решаю что: systemd или openrc.

единообразие и простота в написании юнитов для разных целей

Это есть и в openrc. Более того, инит скрипты хороши тем, что разу понятно как это работает, и ты можешь на это повлиять. Например, есть скрипты, где запуск происходит в несколько этапов; как-то мне нужно было понять на каком этапе происходит сбой; я просто дописал в скрипт команды для отладки - и быстро всё выяснил.
Сервисы - набор конфигурационных данных, которые ты скармливаешь в черный ящик, а потом читаешь тонны документации, описывающей нюансы. И если он вдруг заглючит, тебе ничего не остается как молиться на скорый выход патча.

вместо cron есть таймеры

Чем это лучше cron?

монтировать разделы можно с помощью mount-юнитов

Чем это лучше fstab?

Тебе не станет хуже от того, что система начнёт загружаться быстрее

На 1-3 секунды? Извини, я не верю в магию, а при том же результате, бенефит от распараллеливания сервисов именно такой. Я интересовался этим вопросом: всё «ускорение» systemd связано с а) распараллеливанием (результат: показался рабочий стол, но система еще грузится, и работать невозможно) или б) отложенным стартом (см. ниже). Да, распараллеливание оптимизирует I/O + CPU; аналогично влияние bash интерпретатора + внешних команд: есть, но не велико; итого, суммарный бенефит получается в несколько секунд. Если у тебя другая инфа - говори.
Потом - кому по-настоящему важна скорость загрузки, ставят ssd или используют suspend to RAM/disk - там КПД намного больше.

подчистка за всеми — например, если у тебя упадёт DE, то можно быть уверенным в том, что его ошмётки корректно прибьются;

Например? Что может пойти не так. Много раз прибивал разные части DE с помощью убирания kwin/плазмы или Ctrl+Alt+Backspace, всегда всё перезапускалось нормально.

как пользователя, вдруг упал cups или bluetoothd, то меня меньше всего волнует то, что «для его падения есть причина, и авторестарт вреден, потому что её скрывает».

только ты поймешь что что-то не так с сервисом, когда наматеришься на плохо работающее bluetooth устройство, или прерванную 20-ю попытку переписывания файла. Хотя, возможно, проблему можно было бы устранить сразу. Это все равно что люди глотают обезбаливающие таблетки вместо того, чтобы прийти к врачу и вылечить болезнь.
Кроме того, есть риск циклического рестарта, который выест все ресурсы, и вот его-то будет сложнее починить, особенно если сервис в автозагрузке.

[systemd] запуск по требованию — аналогично; зачем мне на ноутбуке постоянно запущенный cups, sshd или samba?

Чтобы уменьшить время доступа к сервису, когда сервис действительно понадобится; экономия ресурсов здесь ну совсем не применима. Ты не думал для чего ставят pre-load, pre-link?
Плюс, при запуске могут быть ошибки: я лучше выясню это в самом начале, чем когда мне срочно нужно будет распечатать документ или расшарить файл.

Можно, но с systemd удобнее. И я про вменяемый мультисит; до logind его не было.

Кроме флешки - есть кейсы/описание? Погулю, конечно, но если есть ссылка на хорошее описание, дай пожалуйста.

Нет хорошего описания, поскольку задача нишевая. Но в идеале это zero-configuration мультисит.

Например? Что может пойти не так.

Не помню, последний раз сталкивался с этим в до-systemd'шную эпоху :)

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

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

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

От циклического рестарта есть защита, внезапно. systemd пишут люди не глупее нас :)

Чтобы уменьшить время доступа к сервису, когда сервис действительно понадобится; экономия ресурсов здесь ну совсем не применима.

С 500 мс до 50 мс? Обойдусь, память дороже.

Ты не думал для чего ставят pre-load, pre-link?

Для того же, для чего аудиофилы прогревают провода (как вариант — для того, чтобы запускать линукс на микроволновках). Эти костыли уже давно не дают никакого заметного прироста.

Судя по тексту, ты не понимаешь, зачем тебе другая система инициализации. Просто «хочу». Ну чтож, дело твоё, имеешь право, можешь и т.п. Но от себя скажу, что я сижу на gentoo, но (!) сознательно выбрал и поставил systemd. Ибо граблей как-то меньше, мне легко и уютно. А если честно, я просто в свое время не стал писать инит для system-wide пшшаудио, а просто воткнул системдэ.

авторестарт

A novice was trying to fix a broken Lisp machine by turning the power off and on.

Knight, seeing what the student was doing, spoke sternly: “You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.”

Knight turned the machine off and on.

The machine worked.

Только не Knight, а скорее Joe Armstrong.

Знаешь, что? Мне плевать на псевдофилософские измышления UNIX-вытиранов и прочей илитки.

А при чём тут UNIX вообще?

я хочу сделать все правильно, просто и правильно

Не сделаешь. Лечись.

Я серьезно, бро. Есть вещи более стоящие, чем наведение порядка там, где он не предусмотрен.

Да, не предусмотрен. Совсем. Уже давно. В любой ОС.