Like it or not Systemd breaks the Unix way and for a certain amount of people (I am not pretending to have a measuring stick) the dogma and philosophy are much more important than perceived ease of use or features.
A conjecture is not automatically wrong. The point of a conjecture is to challenge someone else to prove it wrong. You'd have a hard time showing proof that systemd is niche.
And honestly, it does not break UNIX, let's be serious now. A haphazard bunch of shell scripts is not much better than a monolithic binary, and UNIX does not give a damn either way.
I do not care about dogma and philosophy, I am an engineer with software to run and deadlines to meet.
Sure, but UNIX, with its minimalist philosophy, was - luckily for us! - not created under that slogan. With respect to quality, this slogan has always been the one driving its decrease that we see all around us today.
Sorry to say, yours is a terrible excuse. I respect that you might not like systemd, no software is perfect and systemd has many flaws, but the "think of the UNIX philosophy" is righteous nonsense that I cannot take seriously.
The real world is not black-and-white, with or against us. One of the most beloved UNIX tools, Emacs, is as far removed from the minimalist philosophy that some have decided to be UNIX's crowning achievement. It is not. Linux and UNIX have not won because we're all into minimalism, or dogmatic zealotry.
https://en.wikipedia.org/wiki/Unix_philosophy
Speaking of emacs, it was created outside Unix, to be later reincarnated by Stallman as part of his "GNU's Not Unix" project.
If know shell scripts you can read and adapt the former. You can keep the state in vcs without needing a compile artifact or a compiler.
How much work is it to add a bespoke feature to systemd?
It's a tradeoff for sure, but let's not pretend simplicity has no benefits.
And knowledge of Cron transfers to the bsds.
Cloud computing and the prevalence of highly distributed systems have completely changed how software is deployed, scaled, and managed. These environments often rely on complex orchestration which can stretch the boundaries of the UNIX philosophy towards systems that are more about interactions between distributed components than about simple, single-purpose tools.
I think the only valid-ish argument these Unix philosophy discussions boil down to "why didn't they use purely text based interfaces". Well because they are inefficent and hard to debug and reason with. Making things text only doesn't make them more understandable but they make sure the programs waste energy and development time in meaningless parsing code that is full of security issues.
However "multiple orthogonal multiple orthogonal executables" is just a strawman: their interfaces are unstable and non-straightforward, aand communicate over standardized IPC mechanismsnd one can't reliably replace one of them with an alternative. It's technically true but in practice not. This effectively makes it a huge, inflexible, not-easily-verifiable blob with wide permissions and, potentially, many bugs.
> and communicate over standardized IPC mechanisms
I've never seen that anyone could replace one systemd component with an alternative implementation. Did you?
And now you seriously argue this is brittle, non-straightforward, inflexible, and hard to verify? For real?
If I ever have seen a bloody well designed software system, it is this!