Request for design critique - configuration directories

[Eric S. Raymond]

Achim Gratz <Stromeko at nexgo.de>:
> Eric S. Raymond writes:
> > No. That would gratuitously break compatibility with no-refclock
> > installations that already have a working ntp.conf (or have one
> > generated by dhcp).  There's no reason not to just let that case keep
> > working.
> 
> Again, all the standard invocations that distributions known to me do
> already include the option pointing to the config file.  Anyone not
> using what's delivered with their distribution should be more than
> capable of either providing that switch pointing to the right file or go
> with the flow and move the configuration into /etc/ntp.d as appropriate.

Bad argument.  The usage pattern you observe is not a law of nature, and we
*will* gratuitously piss people off if we do as you suggest.  No: forcing
the use of -c is a non-starter. Admins would wonder why were fscking with
them, and they'd be right to wonder.

Please remember that the people we're trying to win over are a
conservative and suspicious lot - they have to be, because unstable
infrastructure software inflicts high costs. Their tolerance for
changes they might perceive as annoying and gratuitous is limited, and
I choose to spend that budget only places where doing so has much
higher value than we could get from this change.

You're familiar with the term "bikeshed"?  A few days ago in
conversation with a friend I coined the related term "bikeshitting".
This is what happens when someone evaluating your software gets
snagged on a superficial misfeature, it triggers their detectors for
bad work, they ignore everything much larger that you got right, and
you lose that design or deployment win when you shouldn't have.

One of the house rules here is *don't create bikeshitting triggers!*

(My friend has some exciting ideas for forward-compatibly modifying C
so it become provably type-safe and includes parametric types.
Unfortunately he's also got the idea that he should fix C's
declaration syntax in one corner case where the new features interact
with it in ugly ways.  That syntax change, unrelated to the meat of
his type-safety improvements, is a bikeshitting trigger. I'm trying to
persuade him to drop it.)

> > My model here is the way apache2 config snippets work.  What's your
> > actual issue with it?
> 
> My issue is that every single one of those config directories works
> slightly different and you're proposing yet another gratuitous addition
> to this already cluttered landscape.

You are both absolutely correct and making an argument that turns on
you.  There are a zillion variations on how to structure a
config-snippet directory because nobody has yet figured out a
sufficiently right thing to become standard practice.  If there were,
we'd both know it and we wouldn't be having this conversation.

I conjecture that's because this area of design space has no stable
attractor - that is, it's not just that we don't know what the right
thing is, it's that there isn't one.  

But it does not matter whether this conjecture is correct or not.
Either way, when there's no known Right Thing to do, designing the
zillonth and first variation has low costs.  And who knows, it
might be the Right Thing. I think of adaptive radiation in Darwinian
theory here.

However, even though I think these are poor arguments, your proposal
for the directory structure deserves evaluation on its own merits.

> Besides, I really think it's cleaner and more easily followed to just
> run through all config files in a directory (in lexical order if you
> must) without regard to the file name, a prefix or a suffix.  For a
> packager it makes no difference if they rename a file or (sym)link to a
> file in som other directory.  That structure also makes it really easy
> to keep several configurations at hand, you just have to rename the
> directories to swap from one to the other.  So following the example of
> fontconfig you'd have:
> 
> /etc/ntp.d/
> /etc/ntp.d/ntpd/
> /etc/ntp.d/refclkd/
> /etc/ntp.d/ntpd.avail
> /etc/ntp.d/refclkd.avail
> 
> with all config snippets dropped into the *.avail directories and the
> active ones linked into the respective non-suffixed ones, like that:
> 
> /etc/ntp.d/ntpd.avail/snippet1
> /etc/ntp.d/ntpd.avail/snippet2
> /etc/ntp.d/ntpd.avail/snippet3
> /etc/ntp.d/ntpd/active1 -> ../ntpd.avail/snippet3
> /etc/ntp.d/ntpd/snippet1 -> ../ntpd.avail/snippet1
> 
> (I've shown a configuration where one config is renamed to reorder the
> appearance, although typically you would just link onto the same name.

This is all quite reasonable.  Your point that the complexity cost of
a symlink is the same as a rename is valid.  The idea that you can
identify directories with swappable configurations is at least
theoretically attractive.

But there is at least one respect in which your proposal is inferior
to what's now implemented - discoverability.  Your way of doing things
has multiple levels of nested directories, so it's a little tricky to
grasp it as a whole.

My way, on the other hand, all the config snippets (both enabled and
available) are normally at the same level.  This means you get to see
all the snippet names with ls, skim them with "more *", grep them
easily, etc.  I think that slight lowering of discovery costs is
a significant feature.

A thing you don't know about my implementation is that the scan
recurses through subdirectories. So if you want to set up directories
as swappable configurations, I already let you do that (it was the
most elegant way to write the code).  This captures the one advantage
of your proposal.

So you've made a good try, but I'm not seeing functional gain or
simplification over my design yet.  If you want to put forward
other arguments, or modify your proposal, I will consider with
an open mind.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.