The main source of ideological disagreement between pro-systemd and anti-systemd users is just how much an init should handle. Anti-systemd side insists on init being just an init and not exceeding its duties, whereas pro-systemd are willing to make the init handle various other functions, due to the alleged benefits.
I think at this point it's erroneous to call systemd an "init system," it's far more than that and Lennart himself freely admits it in (ironically) the article meant to dispel systemd myths (http://0pointer.de/blog/projects/the-biggest-myths.html):
Well, systemd certainly covers more ground that it used to. It's not just an init system anymore, but the basic userspace building block to build an OS from, but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want.
I'm not entirely sure about how optional the whole package really is. I know for a fact LXC tools like systemd-nspawn, Python bindings, etc. can be removed from the build using ./configure, but I don't know the full extent to judge the veracity of his claims.
Olav Vitters of GNOME and Debian (I believe?) later echoes the same sentiment in a somewhat self-contradictory manner: http://lwn.net/Articles/575790/
Systemd is meant to do one thing and do it well: be the basic building block for Linux.
Of course, one must first define what a "basic building block for Linux" is, although that isn't really elaborated.
Personally, I don't have any strong opinions in favor of or against systemd, but I do feel it was introduced in a rather rushed manner. I think it would have payed off better for the community if people researched certain alternate init schemes that were already present before systemd (not talking about launchd/Upstart), such as Richard Lightman's depinit: https://web.archive.org/web/20050206182736/http://www.nezumi...
However, it's probably a bit late by now, since systemd's place has been set in stone, for better or for worse.
I think at this point it's erroneous to call systemd an "init system," it's far more than that and Lennart himself freely admits it in (ironically) the article meant to dispel systemd myths (http://0pointer.de/blog/projects/the-biggest-myths.html):
Well, systemd certainly covers more ground that it used to. It's not just an init system anymore, but the basic userspace building block to build an OS from, but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want.
I'm not entirely sure about how optional the whole package really is. I know for a fact LXC tools like systemd-nspawn, Python bindings, etc. can be removed from the build using ./configure, but I don't know the full extent to judge the veracity of his claims.
Olav Vitters of GNOME and Debian (I believe?) later echoes the same sentiment in a somewhat self-contradictory manner: http://lwn.net/Articles/575790/
Systemd is meant to do one thing and do it well: be the basic building block for Linux.
Of course, one must first define what a "basic building block for Linux" is, although that isn't really elaborated.
Personally, I don't have any strong opinions in favor of or against systemd, but I do feel it was introduced in a rather rushed manner. I think it would have payed off better for the community if people researched certain alternate init schemes that were already present before systemd (not talking about launchd/Upstart), such as Richard Lightman's depinit: https://web.archive.org/web/20050206182736/http://www.nezumi...
However, it's probably a bit late by now, since systemd's place has been set in stone, for better or for worse.