| 1 |
On Mon, Mar 3, 2014 at 3:16 PM, Wyatt Epp <wyatt.epp@×××××.com> wrote: |
| 2 |
> If the _only_ way to get the config for something is ever to run a |
| 3 |
> specific command specifically tailored for that purpose, then it's |
| 4 |
> evidence of a truly shocking and advanced sadism (not to mention a |
| 5 |
> complete and utter failure of software engineering as a discipline). |
| 6 |
|
| 7 |
I understand what you're saying, but keep in mind that default |
| 8 |
configuration is often determined first and foremost by code. |
| 9 |
|
| 10 |
If everything is right any hard-coded defaults get incorporated into |
| 11 |
config file templates. However, if a config item is commented out, |
| 12 |
there is no actual guarantee that what the system actually does is |
| 13 |
what is indicated in the commented instructions. |
| 14 |
|
| 15 |
That is part of why tools usually exist for dumping the REAL config. |
| 16 |
In the end that is the only way you can be really sure what the |
| 17 |
software is actually doing, between overrides, defaults, incorrect |
| 18 |
comments, and so on. |
| 19 |
|
| 20 |
As I've already commented, I find the most useful approach varies |
| 21 |
depending on how much these files need to be tweaked. In theory I |
| 22 |
could write my own set of udev rules, but in reality few do that. If |
| 23 |
the sourcing of subdirs/vhosts/etc is set up in a clever way for |
| 24 |
apache you can minimize the need to heavily edit a monolithic config |
| 25 |
file. |
| 26 |
|
| 27 |
So a lot of this comes down to the particular application and how |
| 28 |
clever we are with how it is configured, and how much it needs to be |
| 29 |
configured. It also comes down to how much upstream has already |
| 30 |
thought through these problems and presented an elegant solution... |
| 31 |
|
| 32 |
Rich |
Archives