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

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

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

make падает, если одну из целей не удалось собрать, а от системы инициализации всё же ожидается, что всё, что можно стартовать, она стартует

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