> Баш я прибавил, т.к. скрипты пишутся на баше. Я апеллирую к утверждению
> «системд имеет много строк кода на си. Чем больше строк кода
> в процессе инициализации, тем он сложнее и ненадежнее».
>
> Но в случае с sysvinit, bash является частью системы инициализации. Потому надо
> брать исходники sysvinit, исходники bash и сравнивать их.Вообще-то bash частью sysvinit не является. То, что после запуска init запускает скрипт, который производит дальнейшую инициализацию ОС - не делает этот скрипт частью init-а. Если включать в подсчёт сам скрипт, то есть нюанс: в разных осях sysvinit запускает разные скрипты. Где-то они на shell, где-то на python. Из shell-ов это может быть bash, может быть dash, может быть что-либо ещё. Почему же именно bash?
А знаете что ещё? Вместо скриптов для запуска в /etc/init.d могут быть бинари. На протяжении десятков лет можно было использовать бинари вместо скриптов. Главное, чтобы они принимали аргументы start, stop, restart, reload... Что ж нам теперь, gcc в подсчёт включать?
И вот при этом Вы предлагаете включить в подсчёт строк кода не только скрипты, но и один из интерпретаторов? У меня только один вопрос остаётся тогда, который я уже задал: почему Вы не хотите присовокупить сюда ещё код всех бинарных утилит, которые дёргаются этими скриптами?
--
Ну хорошо. Не смотря на то, что bash не является частью sysvinit, давайте сложим. Вот тут рядом пост Митрофанова, по которому получается, что даже если мы сложим, всё равно systemd в проигрыше. Правда, уже не на порядок, конечо. Если Вам с этого легче - да ради бога.
Может быть теперь это для Вас "незначительная разница", но имейте в виду, что эти 100к строчек отлаживали последние 30 лет или около того. Ваша systemd существует в 5 раз меньше, а весит в 3 раза больше.
> Потом, systemd имеет продвинутую систему журналирования (весьма неплохую, кстати. Я люблю
> плейтекст, но переход на бинарный формат для увеличения производительности записи и
> поиска — это правильный шаг). Т.е. сравнение уже неравное получается.
Нет, не правильный.
Раз. (см. #10 - про бинарные логи) https://www.opennet.ru/base/sys/systemd_myth.txt.html
Два. (укороченный до сути вариант предудущего) https://www.opennet.ru/openforum/vsluhforumID3/110582.html#161
> Я хочу прояснить: с теплотой вспоминаю времена, когда стартовал демоны, добавляя их
> в deamons array в rc.conf.
> Но это решение для одной машины. И потом и хорошо помню, как для
> ускорения процесса загрузки предлагалось _экспериментировать_ с
> запуском в бекграунде. Т.е. процесс не автоматизируемый.
Да, я тоже с теплотой их вспоминаю, но ведь современный sysvinit уже давным-давно не такой.
> Системд в этом смысле — это гораздо больше, чем система
> инициализации. Это инициатива, призванная навести порядок в
> запускаемых демонах, ведь необходимо явно задекларировать
> зависимости и т.д..
Так ведь в том и дело, что эта инициатива в дебиановском sysvinit уже имелась на момент создания systemd. Ко скриптам инициализации были добавлены LSB-заголовки, в которых прописали зависимости. Sysvinit стартовал демоны параллельно и разруливал зависимости.
https://wiki.debian.org/LSBInitScripts
Обратите внимание: они были добавлены ещё в Lenny. А это, извините, 2009й. То есть за два года до появления Systemd.
> Это как сравнивать make install с apt-get install. make install проще дебажить,
> кол-во строк кода на си меньше, можно сделать все, что угодно,
> система гибкая, простая, каждая бабушка понимает...
> А с этим apt я не могу легко установить свою программу на
> любую систему, приходится возиться с dpkg, читать плохую документацию и т.д..
Сравнение хорошее, за той лишь разницей, что APT решает реальную проблему: он разруливает процесс доставки и установки огромного количества пакетов. Make же этим не занимается.
А вот systemd не решает никаких старых проблем, зато привносит море новых. Хотите пруфов, хотите? Их у меня много. Вся рассылка debian-russian, а ещё располагаю подборкой комментариев с opennet.
