Hacker News new | ask | show | jobs
by sethrin 4258 days ago
Abstract stateful configuration might be a bad thing, but having a configuration file execute arbitrary, complicated code sounds like a much worse thing to me. I would be interested in differing opinions, but I think in another context the words "executable configuration file" would be a cause for deep concern.
2 comments
smosher_ 4258 days ago
I disagree. If nothing else, there is a lot of precedent for executable code in configuration roles. MTAs, build systems, desktop environments, text editors (vim, emacs, joe, others) and probably a good percentage of the uses of tcl. Problems arising from this don't seem to be universal in any category (except possibly build systems, depending on how you look at it.)

But I have a question: where is this coming from? What makes you think it's "a cause for deep concern?" I would agree it's overkill for most software, but an init system for an operating system like Linux (or configurations for most of the kinds of software mentioned above) is never going to be simple.

link
monstermonster 4258 days ago
I don't know of any executable configuration files on any Unix derivatives. There are init scripts, but they are not configuration; they are instructions.

There are scripts with metadata attached (rc.d items) which may be ambiguous but that is no different from a shared library containing an export table or a set of runtime linker dependencies.

link
sethrin 4258 days ago
Systemd unit files, as far as I am aware, are functional replacements for init scripts. They do contain executable code, which is perhaps unavoidable. However, they are primarily what you would call a configuration file. Given that they are functionally equivalent to init scripts, init scripts must also handle configuration.

You're making a semantic argument, not a technical one. Why is it a good thing that your init system consist entirely of executable scripts? Because to me that sort of arbitrary executable code would be something to minimize: abstract out common functionality, DRY, and have each component do as little as necessary. If you believe otherwise, please support that idea.

link