[arch-general] SystemD poll

Anthony ''Ishpeck'' Tedjamulia archlinux at ishpeck.net
Sun Aug 19 19:17:37 EDT 2012


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.



More information about the arch-general mailing list