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

Well I kind of chuckled when you said

because it couldn't make more clear how (as per /. etiquette, of course, I know) directly jumping to the comment section is your usual MO, when in reality, the occasional guy who actually does spend a few minutes on reading TFA is not unheard of.
Therefore it could have been a funny and subtle troll as well; thanks for ruling out that possibility :).

Besides, It's also very possible that the poster just reads /. the way I do, which is skimming the front page for stories of potential interest (i know, i know), opening them in background tabs, and only /then/ going through the opened stories, eh, comment sections, one by one. So there's quite a delay between clicking on a story (causing comments to be loaded), and actually looking at it for the first time.

Not sure if I should mod you funny or troll, so I'll comment instead.

I like to keep FF running all the time, too, but it (or the javascripts on certain sites) consume just too much CPU. here's my crude cure

#!/bin/sh

if [ -f /tmp/.ffstopped ]; then
pkill -CONT firefox; pkill -CONT npviewer; pkill -CONT plugin-container
rm -f /tmp/.ffstopped
else
pkill -STOP firefox; pkill -STOP npviewer; pkill -STOP plugin-container
touch /tmp/.ffstopped
fi

I.e. it's kind of a toggle. Works best when bound to a key combo of the window manager or so. Process names might also differ on Linux

Actually with all the 3rd party javascripts on here, I'd like to correct my estimate to about 40-50 machines.
Try get a basic clue on what comprises a network.

There were probably around 10-20 machines involved in you posting this comment here. One of them runs Windows.

wtf? for instance?