On Sat, Mar 1, 2014 at 11:06 AM, William Hubbs <willi...@gentoo.org> wrote:
>
> No sir, I was not telling a half-truth.
>
> If the default configuration is stored in /lib/udev/rules.d for example,
> and you can override that default by dropping files of the same name in
> /etc/udev/rules.d, I don't see what the concern is.
>
Oh, that's easy.  The concern is that, as a sysadmin, I have no idea
what the current configuration even is, let alone any idea that the
override is even possible or how the override file is formatted.  This
problem is magnified for every thing that works this way multiplied
again by every instance that the configuration needs to be checked or
changed (because it likely needs to be looked up again because it's in
a non-standard place and we humans don't remember things well if
they're not a constant presence in our lives).

In short: Making life easier for users is why distros even exist in
the first place.  This method lacks transparency and makes life harder
for users.

On Sat, Mar 1, 2014 at 1:31 PM, Alec Warner <anta...@gentoo.org> wrote:
>
> it is easy for a some users to determine, using existing tools (vim, less,
> etc.) to view what the configuration state is.
>
This point is incredibly important:  It should really never require a
search engine to even determine what the current config looks like.  I
don't care if it involves moving the canonical config, or putting a
stub config in /etc with a comment to the effect of:
# This file is for overrides; please see /lib/foo/bar for the default
system configuration.

...or throwing a bunch of code at it to invent a better config
tracking tool (again), or whatever.

Or say "screw it" and this thread dies with no tangible action like so
many others; enjoy your papercuts, users.

> When the default configs are in /lib/udev/.../ and the over-rides are in
> /etc/udev/.../ that is perhaps less clear. Many applications already provide
> app specific tools for this. You can run apt-config dump to dump your entire
> apt configuration (on debian / ubuntu) for example. I'm unsure if polkit or
> dbus have a tool that will read in the configuration and dump what the
> daemon thinks the state would be (if it loaded it.) (puppet has
>
Oh PLEASE don't let this become a trend.  I can't fathom any
legitimate reason to reinvent cat repeatedly.

> gconf, dconf, polkit, dbus, all do stuff like this. I actually find the
> solution somewhat elegant from my side as a sysadmin.
>
I'm curious: how many people have you encountered who even know those
can be configured?  (Never mind things like "how does this work?" or
"what does this even do?"; you've made a very nice list of things
hardly anyone understands. :/ )

Cheers,
Wyatt

Reply via email to