I think in *nix, shell-configured init systems came first and the non-shell config file init systems are a more recent development. The real question is why the non-shell-configured init systems decided to change it up.
I’m far from an expert in init systems, but there are some benefits to declarative approaches for configuration. It’s one of the main reasons yaml and toml are as popular as they are. The short version is, declarative configuration tends to be less verbose, and the declarative contract defines what state you want things to be in, not how to get there which makes it easier on the person writing the unit file, and on the implementers of systemd in that there’s a smaller surface-area to test
Generally declarative:
requires less verbose configuration files, less room for error
is easier to document and easier to understand
leaves the implementers more freedom to improve their system as long as they live up to the agreed-upon contract
is easier for implementers to test/validate. They don’t need to support a scripting language and every single crazy thing someone might try with one but still consider valid
I think in *nix, shell-configured init systems came first and the non-shell config file init systems are a more recent development. The real question is why the non-shell-configured init systems decided to change it up.
I’m far from an expert in init systems, but there are some benefits to declarative approaches for configuration. It’s one of the main reasons yaml and toml are as popular as they are. The short version is, declarative configuration tends to be less verbose, and the declarative contract defines what state you want things to be in, not how to get there which makes it easier on the person writing the unit file, and on the implementers of systemd in that there’s a smaller surface-area to test
Generally declarative:
The declarative approach also allows for better composability - user tweaks can just be the relevant lines on top of the packaged default config.