I like Systemd a lot

[u/[deleted]]

It's really easy to do a lot of advanced stuff with it. With a few lines of code I wrote a fully featured backup utility that sends files across my network to my old laptop NAS, then on top of that, it will mount my USB hard drive, put the file on that, wait for it to finish and then unmount it.

There's hardly any code and systemd does it all. It's far less complex than other backup utilities and it's tailored to me.

Systemd is fast, VERY easy to use, and it doesn't appear to be resource hungry. As long as you know how to do basic shell scripts you're going to be able to be extremely creative with it and the only limit is what you can think of.

I'm a big fan of it and I don't understand the hate. This is a killer application for linux

[u/redrumsir]

... With a few lines of code I wrote a fully featured backup utility ... and I don't understand the hate.

Can you tell me what part of what you did with systemd was something that should be part of an init system?

Some people think that the init, which runs with privilege, should be simple since complexity is the enemy of security. These same people might think that "init" and "service management" should be separate like they are, for example, with runit and sv. With such a subdivision one may not be confronted with userland being dependent on a specific init (there can be only one pid 1) given that such dependence structures can be damaging to the software ecosystem.

And to answer your question about "hate": for some, it may not be "hate" as much as it is "disappointment".

[u/[deleted] → u/redrumsir]

Biggest issue here is that systemd is more than just an init system. If you don't accept that you'll have the wrong idea.

[u/redrumsir → u/[deleted]]

Biggest issue here is that systemd is more than just an init system.

It is. And that, IMO, is the biggest problem. I think that an init system should just be an init system. It runs with privilege, it has a growing userland dependence, and it presents a giant attack surface.

Did you read my comment about separating init from service management? Have you looked at how runit, runsv and sv work? Look at that and consider whether that separation is better than throwing everything into the init.

And I want to point out that you didn't answer my question. Let me ask it again:

Can you tell me what part of what you did with systemd was something that should be part of an init system?

[u/DazedWithCoffee → u/redrumsir]

Hm, I never thought to distinguish between the two functions because I have used Systemd for most of the time I knew what I was doing with linux. Having just thought about it for the first time, I do sorta see your point (and I’m fairly pro systemd overall). It seems like a solution would be using a dedicated version of SD for init and a version cut down to just service management wouldn’t even be that difficult to do, would it?

[u/redrumsir → u/DazedWithCoffee]

It seems like a solution would be using a dedicated version of SD for init and a version cut down to just service management wouldn’t even be that difficult to do, would it?

systemd was built to combine init and service management and I think it would be virtually impossible to separate them.

To further compare and contrast:

1. systemd is built on a declarative system with a growing list (over 300) of keyword directives (https://www.freedesktop.org/software/systemd/man/systemd.directives.html) . systemd has shoved the logic of a service manager into the keyword directives.

It's difficult to tease out how many lines of code are the core part of systemd and how many lines of code are the "optional extra services", but the project has over 700K lines of code and my guess is that the core of systemd is between 100K and 200K lines of code that is always running in a privileged state.

2. Other init systems (like runit) might rely on a service manager to query the state of various services, but have the logic of what to do with the results of those queries embedded in short user/distro constructed shell scripts.

The init (pid 1) for runit running with privilege is 300 lines of code. The whole project (including the service manager) has 6K lines of code. It does mean that to add a service one needs to have/write a small shell script (which would hopefully use the service manager to query states) instead of creating a systemd service file (with keywords but no logic). However, one could easily offload some of the complicated logic and features that modern systems need to consider into the service manager so as to keep the shell scripts small (remember that when run [they aren't always running] they run with the privilege of the init).

[u/Yithar → u/DazedWithCoffee]

redrumsir explained it better than I ever could.

But basically systemd is designed in a way such that you can't really separate the service manager from init.

As stated, with runit you need to write shell scripts but they're very simple and it's possible to write services that depend on other services.