Hacker News new | ask | show | jobs
by monstermonster 4257 days ago
Not really a deep Linux user here but systemd brings the bad bits of windows to Linux: Abstract stateful configuration, black boxes and communications to do simple tasks. As someone who supports lots of software built on this approach (windows desktop) then I will assure you it's a pain in the butt big time.

Sure it may work for you but if N machines have state A and P machines have state B then getting all N and P machines to state B is incredibly difficult. It looks easy until you do it. That's probably one of the largest and most common things we do when deploying more than a trivial single machine.

To put it into perspective, everything becomes as much of a PITA as RPM packages without yum.

That was immediately obvious to me when I installed CentOS 7 on a couple of test machines to replace our costly Riverbed appliances and timedatectl threw "failed to issue RPC" on one machine but not the other. Same steps to install.

That's where we don't want to go.

We are now running FreeBSD and nginx on a HyperV cluster.

1 comments

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.
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.

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.

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.