You do not have to use all resources that are under the systemd umbrella. That's just BS, sorry. And prod deployments breaking... Well I guess that never happened with those best-managed sysv init scripts? Guys, pick your fights reasonably.

▲ benj111 3 hours ago | parent | next [-]

There's only the optionality because of the pushback though.

One element of the free software culture is pushback against monolithic software. It allows you to swap out components in this way. Without that culture there wouldn't be the choice. You could disagree with a particular manifestation of that culture, but at least understand and accept that culture and accept that the reason why you perceive this to be a non issue is precisely because of that culture.

▲ shevy-java 3 hours ago | parent | prev | next [-]

Agreed. But you still need to know what to enable/disable, so more complexity is the outcome.

> And prod deployments breaking... Well I guess that never happened with those best-managed sysv init scripts?

Which of these two has the larger surface area? I would assume there are more problems in systemd simply because it has a lot more code.

> Guys, pick your fights reasonably.

I don't see what is not reasonable here at all. Can you explain this? In particular I would like to see your explanation how more code means less issues, all other things considered being equal. And that's just the code - there are many additional issues, documentation, maintenance and so forth.

▲ gf000 2 hours ago | parent [-]

Not all code are equal.

There is an essential complexity you need, period. This is a fundamental truth that that can never decrease.

And init and service management is a generally hard problem - like a static approach wouldn't bring you too far, you have services activated at runtime, modules appearing, disappearing etc.

So it's a hard problem, yet many parts are repeating. A network service and a file system mount both require some kind of dependency management, parallelism with locks, logging etc. On top, a declarative approach is far better for such a dynamic system and that's exactly what systemd is.

OpenRC gives some of this, but bash is an abomination and anything larger than 2-3 lines will have bugs. I don't really see what it's giving you over an open-source binary that parses trivial .ini-like files that have pretty good portability across systems.

	▲	adrian_b an hour ago \| parent \| next [-]
		Init scripts should not need significantly more than a few lines. I do not think that I have ever used an init script longer than 1 page of text. If bugs are feared, it is always possible to invoke a script written in another scripting language. While some people like Python for this purpose, in the past I had good results by using scsh for complex scripts where one wants to avoid bugs. "scsh" is a Scheme dialect specially designed for replacing shell scripts, i.e. where you have a convenient syntax to express the features of a shell scripting language, like writing command pipelines, file redirections, etc. Even a zsh script can avoid the most frequent errors from bash scripts, which are caused by the incorrect use of quotation. With any scripting language, it is possible and recommendable to use strictly declarative init scripts, which only contain definitions of variables and parameters for invocations, separating the procedure definitions in distinct files, which are common to any installation and which are not modified for a custom configuration. Even when it may be desirable to implement some functions of the init system in binary executables, those must be extremely simple, as demonstrated by the small executables included in the daemontools of Daniel J. Bernstein, and not like the big monstrosities of Systemd.
	▲	simoncion an hour ago \| parent \| prev [-]
		> OpenRC gives some of this, but bash is an abomination and anything larger than 2-3 lines will have bugs. I don't really see what it's giving you over an open-source binary that parses trivial .ini-like files that have pretty good portability across systems. Hey, hun. Here's an OpenRC service file that's nearly as small as it can get. [0] I don't know about you, but that OpenRC service file looks a whole hell of a lot like a Unit file to me. Do you disagree? If you replace line 14 with `supervisor=supervise-daemon` and remove the "-D" from 'command_args' to make avahi-daemon run in the foreground, then you don't have to deal with "icky" pidfiles, and you get daemon supervision and automatic restart on failure. OpenRC also does parallel service start and stop. I've been using it for... ten years now with no problem. [0] <https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...>

▲ ErroneousBosh 3 hours ago | parent | prev [-]

I've never *ever* broken a production system by reconfiguring a sysvinit service, at all, no no no, not me...

	▲	adrian_b 2 hours ago \| parent \| next [-]
		For production systems, I started more than a quarter of century ago with FreeBSD, which at that time was still much more stable and more performant than any Linux variant. Even then, the init scripts system of FreeBSD was much better than the traditional sysvinit. I have never ever had the slightest problem with it, since then until today, when I still run a mixture of Linux and FreeBSD servers. In the following years, many features of the FreeBSD software package system and of its init scripts system have become available in some Linux distributions, especially in Gentoo. I have never used in production any variant of the traditional sysvinit, while with the improved versions from FreeBSD, Gentoo and a few others I have never seen any difficulty and no feature that could have been improved by the use of systemd. In my opinion, the way to an optimal init scripts system has been shown by Daniel J. Bernstein with his "daemontools", which I have also been using continuously 24/7 for more than a quarter of a century, for some essential services, on many servers. Today, there are a few new init scripts systems that have been inspired by the DJB daemontools, and I think that one of them could become the best choice in the future.
	▲	LetMeLogin 3 hours ago \| parent \| prev [-]
		Absolutely not!