Ну так упомянутых как раз и стало практически нереально юзать на десктопе или сервере. Что вам не нравится? Первое тестовый полигон редхата. Второе - с современным софтом мучительно без датацентра под билдферму. Третье - набивка контейнеров безблагодатная, а больше я это нигде и не видел.

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

Добавлен по принципу "ну типа нехорошо иметь такой #define".

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

Особенно в init, ога! Остается подумать что будет если динамическая аллокация обломится когда в системе наступит душняк с памятью - и как вам будет такой оборот.

Хинт: если падает init - ядро улетает в панику. И вот тут большой вопрос захочется ли вам именно динамическую аллокацию, именно там. Потому что так можно получить - систему падающую в панику при намеке на душняк с памятью. Круто, а? :)

Проблема не возникала, поскольку все давным давно на systemd сидят. Вот кто-то решил скачать sysvinit, чтобы посмотреть, как диды программировали, а там такое недорозумение.

Sysvinit был написан 1983м. 42 года.

не "давай я прочту это бегло", а именно внимательно чтоб увидеть ашипки.

мониторч там выдают здоровенные, а вот длина строки во всех стайл гайдах ограничена 80 знаками.

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

если совсем на пальцах - длинные строки читаются быстрее, а короткие - внимательнее.

оптимальная ширина печатного текста в 60 знаков тоже не на голом месте выведена.

Байты. Иероглифы быстрее исчерпают

Нисколько не удивителен. Shell должен быть быстрым и потреблять мало памяти. При данных требованиях реализация в виде однопроходного интерпретатора -- вполне естественна.

К слову "быстрый" нужно добавить кучу оговорок. Начиная с того, что стандартные конструкции нужно заменять на xargs, а так же то, что порождение дочерних процессов вроде sed и grep не сказываются положительно на быстродействии.

Ну его позиция заключается в том, что в systemd есть daemon-reload, который единовременно прогружает все юниты, а потом держит в памяти. Это конечно хорошо, это решает гипотетическую проблему конкурентной правки файла скрипта, который одновременно исполняется. А мы на это смотрим прохладно лишь потому, что у нас никогда не было таких проблем: ну просто потому, что инит-скрипты правятся обычно не так уж часто, в основном катятся шаблонизаторами (а они создают сначала новый файл, а потом мувят по таргету), прогоняются одноразово, а супервайзинг вообще реализовывался отдельными утилитами, а не средствами собственно шелла. И естественно у нас нет информации о том, что кто-то попадал в подобную ситуацию, каковую парень описал: потому что если бы этот кто-то был способен отдебажить её, то он бы в ней банально не оказался.

Это довольно скучно. Мы им говорим -- ааа, у вас "0" в предыдущей версии значил одно, а в новой другое. Мы говорим -- ааа, вы пропустили багу из-за которой по дефолту домашние каталоги пользователя удаляются. Мы говорим -- ... а впрочем много чего мы говорим. А они нам в ответ "зато у вас нет гипотетической проблемы, которую мы выдумали". Ну что ж, спасибо им хотя бы за намерения. =)