Systemd 198 Brings "Many Big Changes"

[Ericg]

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.

[Ericg]

EDIT: When is systemd going to go fetch my email for me? When is it going to synchronize my phone for me? When is it going to -be- the firewall. When is it going to render opengl for the gpu drivers... etc, etc... Where is the line in the sand going to be drawn?

Everything systemd does is related to service management in some way.

When is it going to fetch your email for you? Never. But it will start the service that will.
When will it sync your phone? Never, but it will start the service that will. When is it gonna be the firewall? Never, but it will start the service that will.
When will it render the opengl for the gpu drivers? Never..its not hardware o.O

[Teho]

Everything systemd does is related to service management in some way.

Well that's not quite true anymore with the addition of kernel-install and bootctl in 189 (of course those are separate from the systemd process itself). Both of those deal with booting the system though.

There's this interesting snippet on /r/linux:

Release 198 i stats:
644 commits
in 2 months
by 49 authors
from 7 distros (afaik, by doing author->distro)

-phomes

It's interesting how systemd-bootchart has evolved since it was merged. Before it was hosted separately it was only developed by Auke Kok. Now after being part of systemd for few months it has had commits from eight or so developers. I think that shows why it makes sense to bundle some of this software together even if it isn't absolutely necessary.

Now I just can't wait for Arch Linux to complete their work on pushing systemd to initframs.

[Hamish Wilson]

When is it gonna be the firewall? Never, but it will start the service that will.

systemctl start firewalld
systemctl enable firewalld

[bkor]

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?

People have explained to you all the benefits in great detail many times. I also did that.

Bad manner: explain. Seems again like your 'it is buggy claim'. According to Fedora Bugzilla, systemd is not buggy. According to Mageia Bugzilla, systemd is not buggy.

Back up your claims. Don't repeat things that have been refuted or replied to.

You keep repeatedly asking why people are defending systemd. Read the comments already! Jeez!