On 03/03/14 23:13, Rich Freeman wrote: > On Mon, Mar 3, 2014 at 3:16 PM, Wyatt Epp <wyatt....@gmail.com> wrote: >> If the _only_ way to get the config for something is ever to run a >> specific command specifically tailored for that purpose, then it's >> evidence of a truly shocking and advanced sadism (not to mention a >> complete and utter failure of software engineering as a discipline). > I understand what you're saying, but keep in mind that default > configuration is often determined first and foremost by code.
Which is why should shouldn't be calling the files in eg. /lib/udev/rules.d configs, but rather defaults which are unrolled from the applications code. Far better to have the defaults unrolled into whatever formatted file than have it built-in hidden in the applications code. Thus, doesn't matter if it's XML or JavaScript or whatever, all those files belong to /lib just fine if needed in early boot, long as they are defaults that are read-only, not the actual configs, which are by definition not read-only. I'm not saying you, but in general, including in this thread, there seems to be some people actually agreeing but not knowing about it when another is speaking of configs and another is referring them as something else. > > If everything is right any hard-coded defaults get incorporated into > config file templates. However, if a config item is commented out, > there is no actual guarantee that what the system actually does is > what is indicated in the commented instructions. > > That is part of why tools usually exist for dumping the REAL config. > In the end that is the only way you can be really sure what the > software is actually doing, between overrides, defaults, incorrect > comments, and so on. > > As I've already commented, I find the most useful approach varies > depending on how much these files need to be tweaked. In theory I > could write my own set of udev rules, but in reality few do that. If > the sourcing of subdirs/vhosts/etc is set up in a clever way for > apache you can minimize the need to heavily edit a monolithic config > file. > > So a lot of this comes down to the particular application and how > clever we are with how it is configured, and how much it needs to be > configured. It also comes down to how much upstream has already > thought through these problems and presented an elegant solution... > > Nod.
