[josteink]

Simple... for what?

I’d like to setup a service, which depends on another service, and which must always be running, and if it goes down, it needs to have all forked processes killed, must be restarted, and it needs to run as a specific user.

With systemd? 5 lines or so of boilerplate, independent of distro.

I don’t know about you, but I call that simple.

[majewsky]

Technically (and I think this is what this thread's misunderstanding is coming from), this is not systemd being simple. It's systemd being easy.

Simplicity is an intrinsic property of a product, describing that it solves a problem without needing many parts. Easiness is a property of the product's user experience, describing that it can be used without much training.

[squeed]

Systemd reflects the underlying system it is meant to support: the Linux kernel. And the Linux kernel is neither easy nor complex.

That Systemd can make the mania of Linux knobs usable is, IMHO, a huge achievement.

[downerending]

I've run across a couple of cases where the "depends on" part seems to intermittently fail. That is, the implementation seems to end up with a race. That presumably means that the dependencies were specified incorrectly, but getting it right seems to be quite difficult. Or, conceivably, it's a bug in systemd, but debugging that is a lot harder than debugging a couple of tiny shell scripts.

I'm not necessarily a "remainer" on the subject of systemd, but I think it's not correct to sell it as a huge win on simplicity. Maybe it is simple when everything goes right. When it doesn't, though, systemd is fairly nasty to deal with.

[kelnos]

I think this subthread is talking about the complexity of a system's implementation, not that of its user interface.

[josteink]

As a user, systemd wins for me hands down, because it is simple to use. That it masks complexity away from me is a feature, not a bug. This is also why distros is implementing it almost everywhere: It makes their job easier.

Now if you are measuring the complexity of the system's (full) implementation, you can't really compare systemd to to SysV-init. You need to compare a systemd-based system to a SysV-init based system.

And then you need to account for the 100s of inconsistently written shell-scripts, all the code distributed in the mess of third party dependencies (sh, bash, Perl, Awk, Python, su, supervisord, cron, etc) to ensure that the functionality of the systems you are comparing is really somewhat equal, not to mention the added complexity of the glue between all those components, and how it may fail.

And when you do that comparison, I do believe you will end up concluding that 1. full systems are somewhat complex, for both systems, and 2. that systemd-based systems are not fundamentally more complex, and 3. systemd-based systems have the benefit of a single, centralized implementation for all these core functions, so that developers don't have to reimplement them inconsistently, and possibly buggy.

With systemd, for better or worse, either your entire init-chain is broken or it isn't, so when it works, you know it works. With SysV-init you have no such guarantees.

[esarbe]

Downvoted for truth, I guess?

[rcxdude]

The implementation of a correct version of the above in sysvinit is no less complex, especially in its emergent behaviour.

[duncan_bayne]

... which is as I recall, one of the main differences between the New Jersey Style and the MIT Style (per Gabriel).