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

зачем ЕЩЕ один бинарник который делает то же

См. ниже.

Но если бд может так взаимодействовать с systemd то что мешает научить взаимодействовать chrony и сообщать когда оно уже выставило правильное время? Зачем было еще один велосипед изобретать?

Затем, что миллион велосипедов, и с каждым нужно взаимодействовать. Добавление поддержки еще одного создает нагрузку на разработчиков и администраторов, потому что это еще одно уникальное сочетание софта, в котором могут быть специфические баги и проблемы. Это простая комбинаторика: чем больше вариантов - тем сложнее тестировать и поддерживать. Поэтому проще сделать поддержку чего-то одного, которое устроит подавляющее большинство, а остальные пусть подстраиваются (что не сильно большая проблема, потому что не устраивает их оно, в основном, по религиозным причинам).

Обычно глубинные фанаты юниксвея и юникса оный юникс сами в глаза не видели, и поэтому думают, что отход линукса от велосипедостроения - это зло и виндузятничество. А на самом деле, классический Solaris и суровый AIX буквально так и построены, в духе «собора», а не «базара». Знаешь, как в солярке поднимается сеть? ifconfig le0 dhcp start, который запускает демона. Всё интегрировано и связано, всё взаимодействует с соответствующими подсистемами, а не криво склеено скриптами со слипами.

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

декларативное описание инициализации в случае например радиомодемов

Точно так же как и с NetworkManager, там тоже используется декларативное описание. Я как раз в прошлом году интересовался, в networkd модемы еще не занесли, но работа ведется. Пока что рекомендуется использовать рядом NetworkManager+ModemManager, который управляет только одним указанным интерфейсом.

Вполне возможно что наведения порядка в инициализации системы приведет к сокращению дистро-специфичных скриптов и конфигов которые они читают.

Так уже. Сейчас все дистрибутивы с systemd работают плюс-минус одинаково. Есть всякие особенные, типа Debian, которые не до конца искоренили некоторые свои специфичные костыли (потому что они ближе к телу), но в остальном процесс идет. Мой софт отлично запускается как на арче, так и на том же дебиане, все 19 подсистем.

зачем ЕЩЕ один бинарник который делает то же

См. ниже.

Но если бд может так взаимодействовать с systemd то что мешает научить взаимодействовать chrony и сообщать когда оно уже выставило правильное время? Зачем было еще один велосипед изобретать?

Затем, что миллион велосипедов, и с каждым нужно взаимодействовать. Добавление поддержки еще одного создает нагрузку на разработчиков и администраторов, потому что это еще одно уникальное сочетание софта, в котором могут быть специфические баги и проблемы. Это простая комбинаторика: чем больше вариантов - тем сложнее тестировать и поддерживать. Поэтому проще сделать поддержку чего-то одного, которое устроит подавляющее большинство, а остальные пусть подстраиваются (что не сильно большая проблема, потому что не устраивает их оно, в основном, по религиозным причинам).

Обычно глубинные фанаты юниксвея и юникса оный юникс сами в глаза не видели, и поэтому думают, что отход линукса от велосипедостроения - это зло и виндузятничество. А на самом деле, классический Solaris и суровый AIX буквально так и построены, в духе «собора», а не «базара». Знаешь, как в солярке поднимается сеть? ifconfig le0 dhcp start, который запускает демона. Всё интегрировано и связано, всё взаимодействует с соответствующими подсистемами, а не криво склеено скриптами со слипами.

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

декларативное описание инициализации в случае например радиомодемов

Точно так же как и с NetworkManager, там тоже используется декларативное описание. Я как раз в прошлом году интересовался, в networkd модемы еще не занесли, но работа ведется. Пока что рекомендуется использовать рядом NetworkManager+ModemManager, который управляет только одним указанным интерфейсом.

Вполне возможно что наведения порядка в инициализации системы приведет к сокращению дистро-специфичных скриптов и конфигов которые они читают.

Так уже. Сейчас все дистрибутивы с systemd работают плюс-минус одинаково. Есть всякие особенные, типа Debian, которые не до конца искоренили некоторые свои специфичные костыли (потому что они ближе к телу), но в остальном процесс идет. Мой софт отлично запускается как на арче, так и на том же дебиане, все 19 подсистем.

зачем ЕЩЕ один бинарник который делает то же

См. ниже.

Но если бд может так взаимодействовать с systemd то что мешает научить взаимодействовать chrony и сообщать когда оно уже выставило правильное время? Зачем было еще один велосипед изобретать?

Затем, что миллион велосипедов, и с каждым нужно взаимодействовать. Добавление поддержки еще одного создает нагрузку на разработчиков и администраторов, потому что это еще одно уникальное сочетание софта, в котором могут быть специфические баги и проблемы. Это простая комбинаторика: чем больше вариантов - тем сложнее тестировать и поддерживать. Поэтому проще сделать поддержку чего-то одного, которое устроит подавляющее большинство, а остальные пусть подстраиваются (что не сильно большая проблема, потому что не устраивает их оно, в основном, по религиозным причинам).

Обычно глубинные фанаты юниксвея и юникса оный юникс сами в глаза не видели, и поэтому думают, что отход линукса от велосипедостроения - это зло и виндузятничество. А на самом деле, классический Solaris и суровый AIX буквально так и построены, в духе «собора», а не «базара». Знаешь, как в солярке поднимается сеть? ifconfig le0 dhcp start, который запускает демона. Всё интегрировано и связано, всё взаимодействует с соответствующими подсистемами, а не криво склеено скриптами со слипами.

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

декларативное описание инициализации в случае например радиомодемов

Точно так же как и с NetworkManager, там тоже используется декларативное описание. Я как раз в прошлом году интересовался, в networkd модемы еще не занесли, но работа ведется. Пока что рекомендуется использовать рядом NetworkManager+ModemManager, который управляет только одним указанным интерфейсом: https://docs.pikvm.org/modem/