OpenRC is a variant of the BSD rc mechanism, you pleb, which exactly avoids

this.

We're obviously using "helper script" to refer to different things.

I completely disagree, but I wasn't aware of that there's an accepted definition. Mind sharing the source?

I'd hesitate to call the sysV init scripts "helper" scripts, because they are the central mechanism (apart from lil' init itself). The "central element" of systemd are the parts witten in C, of which there (apart form init itself) is no such equivalent in system V init.

No. I knew you'd bring up something like this, but, no.
The manual way to configure an interface is one execution of the ifconfig(8) program (or whatever is currently hip in the linux world). This is the part that has to be "learned"; you have to remember that the program's name is ifconfig, and that it accepts an interface name, followed by an address family, followed by an address. Or else, that there's a man page. That's the "hard" part, and it's the same (modulo constant NIH-ing of the interface configuration programs due to what probably is an underlying design flaw) on both sysVinit and systemd machines
Now, system V runs that command in a shell script and that's it. If now you feel like objecting "but it means i need to learn the shell!", then here's the important piece you're missing: If you're using a unix-like OS, and you don't know how to handle a shell, then there's your problem. It's the primary user interface. It's not only for running init scripts but provides a direct value for almost every other task imaginable.

Now, in systemd, one has to additionally learn systemd. It doesn't mean you can forget your shell. It does mean, however, that you have to invest significant time to understand and learn the huge piece of shit that is systemd. Apart from professional sysadmins, whose time would be better spent administering their systems, I don't realistically see anyone else going to do that. It's video tutorials and just-do-this-special-trick wiki articles all the way.
Speaking of, is proper documentation at least theoretically available now?

Hahahahah.

No, they won't. But they limit the consequences of human error, which is sufficient.

What kind of arguments do you need here, this follows from common sense. Do you understand what "baseload" is? Hint: It's always there.

Another hint: There's a world outside mum's basement, and guess what? It's not always windy and sometimes it's (gasp) dark.

...two of which are helper scripts...

Not quite, but whatever.

...except for those two helper scripts, yes... They are /not/ required in sysvinit. There's nothing to stop you from doing something like that on system V, but the canonical way would be to do that in the init script. So regarless of whether the helper scripts are an unrelated or an integral part of systemd, using systemd in Arch for the highly complex use-case "static IP address" apparently means one way or another, they have to appear. Stop trying to excuse that away.

Sure, there's nothing wrong with a configuration file. What you're trying to say here, not so sure.

I don't even know what to reply to this ... odd ... statement. I'll grant you the benefit of the doubt and assume you live in some twisted sort of parallel universe where 'nothing related' means 'entirely related' or so..

You're missing the point. I wasn't talking about the point of view of distro maintainers, but the case when you, a sysadmin, first encounter a problem with a script or program. Please, with that in mind, reconsider that part of what i wrote.

(I mostly agree with this, but it's beside the point)

Fair enough. So a twisted parallel universe it indeed is! (just kidding)

Except for the mentioned helper scripts and the whole bloated infrastructure of systemd, sure.

How aren't they related to systemd? I'm not following, I think.

So you see how pointless it is?

Disclaimer: I have a ton of experience in C; i really like the language. But would you please think of debugability? Quickly analyzing and fixing a bug in a script means editing that script. Fixing a bug in a component that is written in C, means a) identifying what part failed in the first place, checking out the entire project, getting it to compile (which tends to include a ton of build time dependencies), of course don't forget to compile with debug symbols. Then either install the debug version, which sucks, or put it somewhere else and hope the part you're fixing doesn't use the non-debug version. And that is even ignoring the actual effort about fixing the actual bug...
A shell script? add a ``set -x'' to find out what's going wrong, edit to fix, which is usually no problem for someone who knows their shell.

Perhaps because I had some impressions with a journey into the systemd world to share? I do manage a few hundred Debian machines at work, so i'm not a complete stranger in the linux world.

Why do you put whitespace in front of question marks?

Or, you know, when there's a way to identify and communicate with said maintainer.

But does the tail meow when you pull the head?

This at +5 Interesting made my fucking day. Hahahahahaha.

Exhaust pipes -- miracles of modern engineering and a fundamental piece of the stability and stiffness of every car!

I sure did look at it (and it made me laugh *even* harder, but that's beside the point).

I'm sure willing to believe that you "know better than me" how to deploy big monolithic number crunchers "globally for a living". Unfortunately for you, this was about networking. (It's a fairly new idea, you might not have heard of it yet).
So I'd suggest you familiarize yourself with the fundamentals of networking, in order to avoid making yourself look like a complete idiot next time

I'm sorry to hear it.

Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).

I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.

No, it's not; and more to the point, I don't have a real "use case". As said:

You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.

The other day I had a spare machine sitting around, and decided to install some "modern" Linux distro, just to get some first-hand experience with systemd. I decided to install Arch. Halfway through the installation, I arrived at the network interface configuration. I do run a dhcpd, but for this test machine, I decided to set it to a static IP address (in 192.168.1.0/24).
For a first quick reference, this is how you would do it on *BSD (the interface being xyz0):

I also faintly remember how to do that on non-systemd Linux, for instance in Debian it's adding 2-3 lines to /etc/network/interfaces.

So far, so good. Now, let's see how this is done when systemd is involved, the following is copypasted right from the Arch wiki

Source
Hilarious, right? It's so simple! And it totally does away with those pesky shell script, yet in order to do something as simple as configuring a static IP, the user is told to create two shell scripts, apart from the systemd "unit file" and the file that contains the actual address.
At that point I nuked the machine and called myself lucky for not having to cope with this shit.

Your comment has too few characters per line (currently 24.9).
Please ignore everything below; /. wouldn't let me comment without it

The log file is expected to reside in the /var/run directory, which may not be writable very early in the boot sequence, and which is erased a little later in the boot sequence. We therefore avoid writing to the file until we believe it's safe to do so. We also assume that it's reasonable to always append to the file, never truncating it. Optional argument $1 may be "OK" to report that writing to the log file is expected to be safe from now on, or "FORCE" to force writing to the log file even if it may be unsafe. Returns a non-zero status if messages could not be written to the file. rc_postprocess Post-process the output from the rc_real_work() function. For each line of input, we have to decide whether to print the line to the console, print a twiddle on the console, print a line to the log, or some combination of these. If rc_silent is true, then suppress most output, instead running rc_silent_cmd (typically "twiddle") for each line. which may not be writable very early in the boot sequence, and which is erased a little later in the boot sequence. We therefore avoid writing to the file until we believe it's safe to do so. We also assume that it's reasonable to always append to the file, never truncating it. Optional argument $1 may be "OK" to report that writing to the log file is expected to be safe from now on, or "FORCE" to force writing to the log file even if it may be unsafe.

Hahahahahahaha.
Oh wait, you're serious? Let me laugh even harder...

not sure why this is at -1

Yep, and that number doesn't even include (managed) switches and good firewalls