1. It now has a lot more attention focused on it, so it will get more scrutiny.
2. Unix admins have always been wary of the bleeding edge; distros are adopting systemd today, but those distros themselves are unlikely to see wide production adoption for a year or two.
3. If the systemd team's processes are not up to snuff, a major distro will fork it and run it themselves. If the criticisms have any merit, others will follow. It's why open source is such a great model for critical system software: it's as pure of a meritocratic model as you can get (well, if you accept the fact that merit is based on adoption.)
Basically, any new critical unix process is going to have these types of issues. The fact that systemd has a lot of support basically ensures it will get a lot of attention and bugs/security holes will be fixed.
Still, the simpler something is, the less scrutiny it needs in the first place. Mind you, I think even sysvinit is too complex for PID 1. PID 1 should do the bare minimum trhat the kernel expects of it (taking care of orphaned processes, handling shutdown requests) and leave the rest to other programs.
On some level I agree with you, but if you look at the things that Apple is able to do with OS X and timer coalescing [1], that central point of coordination becomes critical. You need a mechanism for starting and stopping all things, not just daemons, that plays by a specific, defined set of rules so you don't have multiple processes trying to do the same thing.
On another level, I feel the "unix philosophy" of having a lot of interchangeable modules taking care of small, simple tasks hurt it: each level of abstraction has a performance hit, and having to support multiple components in a modular way makes change management a nightmare. There's something to be said for the elegance of tightly integrated components: you can make assumptions that you couldn't otherwise make in a more modular system. I can see how it would be a problem if systemd were proprietary, but it's open source.
You are right that loose coupling carries a performance hit. Certainly, if your only goal is to increase the boot speed of a desktop Linux box, then systemd makes a lot of sense. That said, there are many other goals and many other kinds of boxes, which, among other reasons, is why the tide is turning against systemd.
"Performance" can many different things, all of which are useful in different contexts. It could be lower power consumption, faster thread performance, more I/O, lots of things.
agree. So far, the only 'performance' case that I've seen made for systemd is in desktop system bootup time. Certainly it won't make my threads go faster or cause significantly lower power consumption, or give me 'more I/O'.
For all other processes except pid 1, the status of processes in the system is in a state of Heisenbergian uncertainty because any process could die and have its pid taken by something completely different between the time you query the process table and the time you take action. So if you want sophisticated monitoring and control of all the processes in the system (and you almost certainly do), it should be done in pid 1.
The minimalist init is neckbeard-compliant, but it's just not enough for a robust modern system. Systemd is the correct design.
1. It now has a lot more attention focused on it, so it will get more scrutiny.
2. Unix admins have always been wary of the bleeding edge; distros are adopting systemd today, but those distros themselves are unlikely to see wide production adoption for a year or two.
3. If the systemd team's processes are not up to snuff, a major distro will fork it and run it themselves. If the criticisms have any merit, others will follow. It's why open source is such a great model for critical system software: it's as pure of a meritocratic model as you can get (well, if you accept the fact that merit is based on adoption.)
Basically, any new critical unix process is going to have these types of issues. The fact that systemd has a lot of support basically ensures it will get a lot of attention and bugs/security holes will be fixed.