> I am sympathetic, but a directory of fragments is very thin syntactic > sugar over having it all in a file.
True...and false. It's not all that thin, because... > It does mean that "update this file if it hasn't changed" is likely > to work on each fragment, rather than failing on something which is a > textual collision but not a semantic one. ...there *are* significant substantive differences. > If what you object to is programs coming with default configs that > are active without the admin passing a test, then please say that. Not quite. It's not about the admin having to pass a test in order to be one of the elite who get to use $PACKAGE. (I know that's going beyond what you actually wrote; it's approximately what I suspect a lot of people will read into what you wrote, whether you meant it or not.) It's more that I don't like automated administration of the "I'm going to put all these pieces in what I fondly hope are the correct places and hide it all from the admin" sort. Never have, and I think I may have finally identified what bothers me about it. This has bothered me for some time, because "I don't like automated admin" isn't accurate or complete - I, like many (most?) admins, automate admin tasks and see nothing wrong with doing so. What bothers me about this kind of automated admin is that, instead of being transparent and encouraging understanding, it is opaque and encourages ignorance and lack of understanding. Indeed, in the more extreme cases, it actively gets in the way of an admin who wants to understand what's going on. (I've seen automated software install procedures so opaque the easiest way to figure out what they actually do is to run them in a union-mounted chroot and, afterwards, pull it apart and look at the upper layer - or do the install on a scratch system and compare it with the original.) > Making the config less fragile about things that are textual but not > semantic merge conflicts isn't the core problem, No, *that* isn't a problem at all. That's not the effect that bothers me. That effect is a good one. The problem is that the mechanism used to achieve that - sharding the config into one file per package or conceptual service - also supports, even encourages, the "just trust the installer (updater, maintenance program, whatever) and don't worry your pretty little head about what we're doing to your system" kind of automated administration, and *that*, I believe, *is* a problem. It's a philosophical problem in that it gets in the way of understanding, which gets in the way of fixing things when the break (they always do, eventually). It's a practical problem in that such procedures tend to explode when faced with a system that isn't exactly what they're designed for - and they often are opaque enough that there is nothing for even a _good_ sysadmin to fall back on as a manual substitute. It's a security disaster in that it's surrendering control of what should be your system to someone else, someone who usually has very different priorities from you. If someone manages to come up with a way to achieve the merge robustness that doesn't support and/or encourage that sort of automated administration, I will quite likely wholeheartedly support it - but I will also be astonished, because I haven't even heard of, much less seen, any such. > and we shouldn't not do that because of concern it might be abused. > That would be like banning cars because they might be used in a bank > robbery. If there were no other uses for cars, or they were minor enough, that might be an appropriate reaction. Indeed, we do do the analog in some cases (details vary by jurisdiction, but you'll have trouble finding one that doesn't do something analogous in some cases). This is a tradeoff. There is a benefit (isolating per-service configuration) and a drawback (automation at the expense of transparency and understandability). I think the drawbacks are the greater; complicating it is that I suspect the drawbacks usually aren't noticed by the proponents of such schemes. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
