The problem is that it comes bundled with a whole bunch of other tools for handling networks, cron, ntp, etc which really ought to be separate projects. By bundling them with the successful init system they're not exposed to the usual Darwinian selection processes that shake out the best free software.
Still, systemd timers are exposed to the usual selection pressures: systemd the init does not rely on systemd timers. They’re a convenient addon that integrates well. But anything more convenient could replace them with no problem (as evidenced by cron still working on systemd enabled systems)
That they're part of the same project is actually a win for me, it helps to make the various components work well together. Also there is a common thread or philosophy in how things are built, making learning easier.
In fact "the system is a single project" approach reminds me of the BSDs, which is arguably better than Linux as far as usability and security is concerned.
I've had this thought as well. The BSDs aren't afraid to go off and do their own thing, and it works for them. I feel like generally the Linux ecosystem is held back by reluctance to break free from ancient conventions and standards like POSIX and such, so I come into this systemd debate skeptical of arguments that it's not "the UNIX way" or that it's too Linux-specific or that it's stepping on other projects' toes, or that it's not the way things have been done before.
The systemd critics have legitimate criticisms which can be addressed through evolutionary improvements, but I don't buy the philosophical arguments that systemd is fundamentally flawed.
People who hate systemd want traditional C API, systemd wants message passing.
If you don't like some of binaries, you can remove them and make your own package. If you don't like a particular implementation you can write your own subsystem that uses the same API (as many projects have done).
Basically its just people complaining that it does work exactly as they want, when in reality message passing is the exact right way to make system like that.
No, they can't. The fact that they're compiled into separate binaries doesn't mean they're independent - they're completely dependent.
First of all, most of these systems are totally voluntary. You can simply not use them. And if you use them, you can replace them with other components that speak the same API if you want.
The binaries talk to each other with a message passing API and that is actually the proper way to make a replaceable component. This has been done quite a few times before for many different reasons.
2. the APIs are very complex and convoluted, with deep state maintained throughout the message exchanges; so complex it's effectively impossible to redo them without basically implementing everything exactly the same way
the fact that some binaries communicate through APIs doesn't mean the system is modular, if the "modules" of the system cannot be used independently for other purposes