On Sun, Jul 24, 2011 at 01:17:50PM -0700, Russ Allbery wrote: > Wouter Verhelst <wouter@debian.org> writes: > > > No. systemd wants to throw out init scripts, because they are shell > > scripts, and Shell Scripts Are Bad!!!1!! oh noes. > > I don't get that impression. Rather, I think both systemd and upstart > want to significantly reduce the involvement of shell scripts in the boot > process for the same reason that I'd love to have the time to eliminate a > lot of them from Debian package maintainer scripts: using a (rather quirky > with interesting portability issues) Turing-complete programming language > is only a good idea when you're doing things that require that power. The > rest of the time, it's much harder to analyze, much less adaptable (you're > often duplicating work in every separate script because helper systems > lag, and if there's a bug, you have to fix it everywhere instead of in one > place), more complicated, and gives people enough freedom to get > themselves into trouble. Much less adaptable? Config files are fixed and non-extendable by themselves. A shell script, because it's Turing-complete, I regard as very adaptable. > Falling back on such a language when you have to do something really > complicated is a good thing to support, but most of the time, you really > want to use a simple, declarative language that says what you're trying to > do and then implement the tools and support to accomplish that in one, > well-tested place. I have to disagree here. In my experience, most of the time such simple languages are not enough (down the road), and people will either start extending and extending them (at which point they're not simple anymore), or replace the solution entirely. Turing complete → Config file → Turing complete → and so on… I think that this cycle will go on and on, until we find a superior solution to both. regards, iustin
Attachment:
signature.asc
Description: Digital signature