On Sun, Aug 19, 2012 at 07:14:29PM +0200, Damjan wrote:
I don't understand why you think parsing is a hard thing. INI files have been around for millennia (in internet years) and both parsers and writers for them are well established in many languages.
The question is not whether it is hard but whether it's a good idea. Things are much more likely to go wrong in parsing than many other parts of a program. When you introduce parsing, or the need to parse, you are necessarily introducing the potential for bugs. You can be a mathematically immaculate programmer and never write bugs and this doesn't change the fact that the room for human error is greater in parsing code or in the data being parsed than in other places. You are correct in assuming that well-covered territory is less buggy than new ground. I assume this is why you mention that parsing's been done for so long. This is important when we consider the following:
Also, bash scripts are also parsed, for better or worse.
This is infinity percent true. Now consider that: 1) Using shell does not introduce a new parsing code-base but instead, uses a code-base that is actively and rigorously used in a multitude of other ways such that bugs are more vigorously identified and corrected. 2) Razor-thin shell scripts (such as those used in daemontools style run scripts) have an order of magnitude less matetiral to parse than their systemd equivalents. Thus, the room for errors in the input data is far, far less; while the versatility of such "run scripts" are far greater -- all with a smaller code base than if you were consuming a config file yourself. Even if you are using a popular config-file-reading library to consume your configuration data, that is still more code and, necessarily, more potential forg bugs than if you did not consume config files at all. Thus, my advocacy for daemontools over systemd.
The benefit of declarative config files is that you can extract information from them by *just* parsing and not by parsing AND running them as is the case for random init scripts.
You are correct and articulate this truth well. It does not invalidate my position; that systemd is unnecessarily complex, that it has greater room for errors than some alternatives (please understand that I am not advocating sysv inits cripts in the least), and that the only reason to adopt systemd is because upstream is making it mandatory. If technical benefit were the only consideration and Arch were developed in a vacuum, daemontools would certainly be a superior choice. Because Arch is part of a greater Linux ecosystem and does not carry the burden of all its development by itself, systemd is probably superior for Arch at this time. This truth has convinced me that devs are making the right call in spite of the fact that most advocacy of systemd is based on some fallacious assumptions.
Also, even making a small error in a Turing complete bash script is much more dangerous than in a declarative file, in which you'd just ignore that line.
By what means do you know to ignore a line? What kinds of errors are we talking about? I'm having a hard time understanding this assertion.