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