I think there's a significant distinction here to be made between "configuration" and "programming".

Do I copy/paste swaths of code that I don't understand and put them in my programs? No, absolutely not, because each line is one I can reason about and want to understand.

But do I copy/paste swaths of configuration files / init scripts / etc, without understanding the implications of every single configuration? Yes, absolutely, because the depth behind each of those options is often irrelevant to me. (until I discover otherwise late at night when an alarm goes off (!!))

I think it is important to distinguish these. I don't think any dev that's done ops work would claim they aren't guilty of the latter, but at the same time I think very few good devs ever, and I mean ever, do the first.

Init scripts are code though. I mean, they're code that's mostly boiler plate, but they're still code - I can do arbitary things in them, reasonably unconstrained by their stated purpose.

Configuration is programming. Perhaps I, being the devops sort, am somewhat alone in this opinion, but I opine it anyway: Configuration is programming. Often very simple programming, but programming nonetheless.

There's a configuration language a Google that's stated goal is that it's not turing complete... and yet it is, because it was a necessity for achieving the expressiveness, and now it's almost entirely unreadable because of the convolutions needed to achieve the real-world solutions necessary in it. There's another that's python based, and widely bashed for being 'too hard to reason about', but it has none of the problems with disgusting 'standard' libraries.

Where I am now, Facebook, has adopted a python based model... and used almost none of python's features. Instead, everything is generated through convoluted lists and dictionaries, and it's treated with very little exception as a json file. This saddens me.

Almost all configuration should be done by libraries with sane defaults. So should programming, even though it's not.

It's definitely not cargo cult programming if the thing you paste becomes a cornerstone of your business, or a foundation of a whole project.

In Pragmatic Programmer the authors talk about "programming by coincidence", I think this would be closer to GP example.

I don't believe this to be so, necessarily. You can copy-paste code AND understand what it does. I'm not sure how this is cargo-cult programming on its own(because it's not). To me creating factories, interfaces, and object hierarchies "because that's how it's done" without understanding why or whether or not it's actually needed is more "cargo cult" programming.

There are certainly people who just copy-paste code without understanding it. As an anecdote(because I'm on a role apparently with this topic) copying C# code off of StackOverflow that does AES encryption but sets the IV to all zeroes.. And not reading the comments that say this is bad practice but a customer constraint...

I guess my point is that a LOT of people seek and implement examples and while some don't understand them some find them extremely efficient and DO understand them.. In fact every time you use a library you are, in effect, copy-pasting code that you are relying on...

Yes, I would characterise a lot of programming as "cargo cult" programming.

I'm not sure what the details are here besides init script, but in this particular case the job is boring and difficult/slow to test. Who wants to reboot their machine all the time to test it?

... Which is why sysv init has taken so long to fix. If it's not obviously broken it won't get fixed.

not applicable either, the code and program structures serve a purpose and the article specifically described removing parts that are not applicable.

Except there's always that nagging feeling in the back of a programmer's head that says, I might need that later.

Silly as it may be with things like git around, I can recall thinking, "maybe we will run this on AIX..." when hacking on a multi-OS shell script.

Not good practice to leave the bloat in, but at least give developers the benefit of the doubt that it isn't outright magic to them.

The part about how people "copied an existing init script or thought ... that init scripts needed LSB headers that looked like this" sounded like it to me.

I didn't initially manage to follow the right sequence of links to find the example[1], but now that I have, the context seems to be that "System V init ignores all of these" (the parts people copied without understanding), so the description still looks applicable to that example. (They serve no purpose at the point in time when they're added by cargo-cultists but cause problems much later when someone/something assumes that they are actually meaningful.)

[1] http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdAndSysV...

In other words, you're willing to try and try to find a way to convince yourself you're not wrong despite having it explained to you already.

good day.