| "I really dislike the idea of having one project handling everything on a box .... The day you have a security issue in systemd we are all fu...." I've heard this argument a bunch, but looking at the actual systemd approach doesn't really convince me that it's the case. There are dozens of binaries, dozens of maintainers, hundreds of contributors. It's comparable to a project with a bunch of parts (think Gnome or KDE only at the systems-level), rather than one big black box that does everything. If there were a single "systemd" program that did all the hundreds of things that the systemd system does, it would be alarming and impossible to maintain. But, it's not. They may be more tightly coupled than some like (I quite like systemd and still find it a little uncomfortably coupled in many places), but that's partially a symptom of doing a bunch of things in new ways. No one built the interfaces needed to do what systemd does in the past, so building systemd took reinventing the universe in some regards. That's actually some of what you're getting when you get "systemd"; things that aren't part of the init system, but existed in some form before and are now being replaced by systemd-provided services. "But yeah there are some real good things in systemd, maybe they should just be taken out of it and spin up in a new project ;)" That becomes more feasible over time. Right now, there's a lot of moving parts. Another reason for the tight coupling is that the way things work together is still evolving as people learn the shortcomings of this new architecture. systemd is not perfect, but it is a bunch of little pieces working together. A security issue in one of those pieces doesn't necessarily mean we're all fucked any more than a security issue in one part of any of the old systems necessarily meant we were all fucked. |