[yfiapo]

I don't know if this is everyone's reasons but for me it is:

- it does too much. doesn't follow the Unix norms of doing one thing and doing it well. things like DNS resolution, time sync, etc all exist as systemd components.

- complexity - similar to doing too much but also just that it is no longer easily inspected and understood imo.

- participates in the Linux cycle of reinventing the wheel, excessively. Linux distros felt like they were changing their service management commands every other release for a while.

- breaks compatibility with BSDs.

I'm sure it solves real problems for real people.. but I don't like it.

[himinlomax]

All of these complaints correspond to deliberate tradeoffs, and while they are correct, the negatives are entirely kffset by the positives.

Doing too much? Well it does a lot, but it does it in one place instead of having each daemon or script do it in their own peculiar, non standard way.

Complexity? The configuration files are deterministic, regular, well documented. Contrast with init scripts.

Reinventing the wheel? Well the old wheel was not quite fit for purpose any more. Gradual evolution only gets you so far, sometimes you do need a clean break even though most clean breaks end up being a failure.

Compatibility with BSD? You may care, I just don't. Not saying it's wrong to care about it, but it's irrelevant for most users.

[hackerfromthefu]

Also it's a big ball of coupled complexity, that quite possibly has subtle backdoors given the providence of how it was created.

[himinlomax]

That's one piece of code to audit, compared to 1000 of init scripts and daemons.