Почему вместо systemd не используют make ?

Потому что NIH.

не верю. Автора бы запинали за них. У него однозначно были весомые аргументы.

У systemd гибридная система из зависимостей и событий, одним make тут не обойтись.

Язабан. Тупняк.

Потому что задача systemd не ограничивается «запустить группу процессов». Их ещё нужно уметь корректно завершать, если настроено – перезапускать, и проч.

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

пришлось бы написать ещё кучу костылей.

А разве не было уже таких готовых костылей в SysVinit ?

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

А разве не было уже таких готовых костылей в SysVinit ?

Чтобы получить тот же sysvinit, вид сбоку?

Единственный профит от systemd - распараллеливание. Вот его одно и надо было добавить, не переписывая всё

Единственный профит от systemd - распараллеливание

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

Это быа цитата: «One of the main problems is, with System V init, all processes are started serially, one after another.» вот из этой статьи - https://www.howtogeek.com/675569/why-linuxs-systemd-is-still-divisive-after-all-these-years/

One of the main problems is, with System V init, all processes are started serially, one after another

Даже если опустить, что это личное мнение автора статьи, – это уж никак не переводится как «Единственный профит от systemd - распараллеливание». Более того, сам автор systemd пишет, что скорость загрузки не являлась главным приоритетом:

Myth: systemd is about speed.

Yes, systemd is fast (A pretty complete userspace boot-up in ~900ms, anyone?), but that’s primarily just a side-effect of doing things right. In fact, we never really sat down and optimized the last tiny bit of performance out of systemd. Instead, we actually frequently knowingly picked the slightly slower code paths in order to keep the code more readable. This doesn’t mean being fast was irrelevant for us, but reducing systemd to its speed is certainly quite a misconception, since that is certainly not anywhere near the top of our list of goals.

на эту тему сломано уже столько копий

Копий чего?

Myth: systemd is about speed.

Именно так этот рак и рекламировали изо всех щелей. Когда выяснилось, что это не так, решили отыграть назад и сделать вид, будто этого никогда не было. Но я-то помню. Я помню!

Поюсую тупак и забан, достаточно погуглить цели и задачи системд

Потому что make – сам по себе уже стыд и срам мира Unix.

https://habr.com/ru/post/138682/

достаточно погуглить цели и задачи системд

Ты гонишь пургу. Вот я погуглил. Цели есть, задач нет:

https://wiki.archlinux.org/index.php/Systemd_(Русский)#Цели

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

Для начала, ответьте на вопрос, почему сам make никто не использует - все сидят на CMake, под капотом которого к тому же тот же самый make. Что говорит о том, что make недостаточно высокоуровневый.

//я бы, кстати, сделал наоборот: систему сборки с синтаксисом systemd

~900ms, anyone?

Я! Я!

3 года назад 700мс до фула включая несколько процессов старт которого зависит от сетевой комуникации...

а вообще бред, таких чисел для системд не существует...

Я из cmake генерю ninja, а не make, тогда быстрее сборка и особенно пересборка идет.

кстати, многие так делают, причём давно, что тоже намекает на уровень нужности make

Ты поехавший что ли?

чего сразу я? https://www.opennet.ru/base/sys/systemd_myth.txt.html

Ну ты же этот бред пишешь.

Напиши нам proof of concept на Make, мы посмотрим и, если будет лучше systemd, перейдём на твой костыль. А пока это всё пустые бредни.

1. make падает, если одну из целей не удалось собрать, а от системы инициализации всё же ожидается, что всё, что можно стартовать, она стартует. Сисадмин будет гораздо счастливее, если демон SSH стартует несмотря на ошибку запуска nginx, а пользователь десктопа будет очень рад, если его DE сможет запуститься несмотря на сбой в работе cups. Ведь чем больше сервисов запустятся, тем проще будет чинить то, что сломалось. Конечно, бывают редкие исключения, когда нужно «всё или ничего», это, вероятно, в первую очередь встраиваемые решения, не предполагающие обслуживание в принципе (и то обычно лучше урезать доступный функционал, чем отказаться стартовать совсем), однако в этом случае используются кастомные решения для инициализации, либо можно заморочиться и настроить нужное поведение с помощью зависимостей между юнитами systemd. Ах да, ошибки бывают не только при исполнении команд инициализации, но и в самом синтаксисе makefile.

2. systemd не только стартует всё, что нужно, но ещё и реагирует на события в реальном времени. Например, перезапускает упавшие сервисы, реагирует на изменения конфигурации оборудования и сети (некоторые сервисы могут запускаться только при подключении или отключении сети, например). Что-то выразить с помощью make можно, но большая часть use-case будет очень костыльной

make падает, если одну из целей не удалось собрать

lol до какого-то времени systemd вешался при загрузке, если один из разделов в fstab не удалось смонтировать. Не знаю, починили ли это.

Ты поехавший что ли?

С разморозкой. Этот поциент генерирует либо тупняк, либо бред. Я удивляюсь, как его до сих пор не забанили.

Почитал статью, в чем стыд не понял. Какое-то нытьё. make мож и не лучший, но вполне нормальный инструмент.