Hacker News new | ask | show | jobs
by yellowapple 4013 days ago
> Again, "read the source" is a sad answer. I can read systemd C sources too, but given that it comes with proper documentation there should be no need to do it.

rc.subr also comes with proper documentation, in the form of the rc.subr manpage, which comprehensively documents its behavior.

Barring that, you're delusional if you think that C is anywhere near as readable as shell in this sort of context.

> My point is that either one has to get some domain-specific knowledge

Arguably less of it in the case of rc.subr, since said knowledge is already part of basic shell scripting knowledge.

> Literally nobody ever claimed that systemd "only goal" is to have terse daemon configuration.

Nor did I. That doesn't change the fact that "OMG initscripts are so verbose with so much boilerplate; my unit files are so much better" is a commonly-cited reason for people to prefer systemd over other init systems, never mind that said reasoning is plainly false.

1 comments

> the fact that "OMG initscripts are so verbose with so much boilerplate; my unit files are so much better" is a commonly-cited reason for people to prefer systemd over other init systems, never mind that said reasoning is plainly false

Indeed, I agree with that. The only advantage is that the restricted syntax of unit files is more suitable for error checking rather than having the shell complain more or less randomly, but compactness is not an intrinsic advantage of it.

That said, not every distribution standardized on such kind of helpers (ie. Debian), so in those cases compactness was one of the benefits of switching to systemd (not exclusive to it).