On 24/09/2015 16:40, Rainer Weikusat wrote:
Hence 'failure' is part of the normal mode of operation and proccesses trying to use TCP need to deal with that.
Yeah, well, if your favorite startup mode is to start everything at the same time and say "eh, if it doesn't work, the program is supposed to handle failure" then your users will give you funny looks, and they will be right. I'm talking normal use cases here, i.e. situations where the services *will* succeed. In those situations, it is better to start everything according to the dependency graph, because then you do *not* trigger failure paths, which is nicer. This does not preclude programs from actually handling failure when it happens, but it's best if failure is the exception, not a normal mode of operation.
That's slightly different because it's obviously not possible to start a program stored in a file (which needs various other files to start) before accessing any of these files is possible (it's still subject to changes at runtime, though). But it's not necessary to declare a dependency on "the filesystem" in a dozen different files and then run some program in order to work out that "The filesystem namespace must be constructed prior to using it!"
And still, "the filesystem namespace must be constructed prior to using it". No matter how you call it, that's a dependency, and that's what I'm talking about. Now, you're free to start daemons logging stuff to /var/log/foo before mounting /var/log, but the reasonable people among us prefer not to do it. ;) -- Laurent _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
