Quote Originally Posted by duby229 View Post
I many other ways do I need to say it? It's bloatware... It doesnt -need- to do just about anything that it does. It is a workaround for a problem that is being addressed in a really bad manner. In addition it tries to be everything for everyone. Where is the line going to be drawn?

What it needs to do is manage services. Anything more than that should be a different project and should be a service. This bullshit integration crap is nothing more than an excuse. It wouldnt need to be modular (which it does poorly, and which LP has publicly stated is temporary) if all these additional functionalities were split out and maintained separately under individual projects and were themselves managed as independent services.
Systemd manages the lifetime of the machine. bottom line. Its the userspace mirror to the kernel.

It handles poweron and poweroff and suspend (three major states of the machine.) Sysv did too. (Not suspend, but sysv was thought of long before 'sleeping' was a thing). Why should systemd do it? Because when you go to sleep you're effectively killing everything. All services need to be made sure they are starting and stopping appropriately on wake up / sleep respectively. Replaces acpid in that regard (Seriously, why did we need a tiiiiiiiiny little daemon just to handle lid open, lid close, and power button push?)

It handles what xinetd used to do because sysV didn't want. Well, what did xinetd do? it started services...but wasn't that sysV's job? well yeah, but sysV didnt want to do it.

It, more specifically the journal, handles logging. Why does it handle logging? Because the services themselves dont. Do you really want every service putting its own logs in different places, of varying quality? systemd starts the service, if the service is killed, or segfaults, systemd needs to know so it can restart it, or atleast flag the service for review.

It handles resource management. Why does it handle resource management? Because under sysV you could get away from your parent process by double-forking. Systemd though has a very tight chain on processes and no amount of forking will ever get a process way from its parent process, or out of its cgroup. Could this be split off into another project? Yeah, it could. But systemd was the first one to go "Hmmm...we could do this..." so it does. The upside is since systemd does it, then resource limits can just be put into the services unit files. What does that do? It means the resource limitations of a service are right there with the services unit file, not off in some other directory. Its a "This goes with this" relationship.

All of the things I listed above-- why does it do them? Easy: force uniformity FINALLY. If you want all the upsides and benefits of systemd, then the distros also have to go "Okay, yeah, all these random bullshit changes we've been making all these years...probably not necessary." If those things were in seperate projects, then the distro could just choose to not adopt that project or convince the developer to join their project and thereby strong arm him into making the changes for THEIR distro's style the new default for everyone else.