On Tue, 2009-02-24 at 12:22 -0600, Callum Lerwick wrote:
On Tue, 2009-02-24 at 12:30 -0500, Colin Walters wrote:
> 2009/2/23 Callum Lerwick <seg(a)haxxed.com>:
> >
> > Yes, constantly re-inventing the filesystem, inside a file, is a much
> > better idea.
>
> It's not reinventing the filesystem, any more than the various systems
> in current /etc are.
I'm not talking about /etc, I'm talking about non-plaintext storage of
configuration.
Dude I'm going to blow your mind: The filesystem is a database. Locking,
atomic transactions and crash recovery (journaling), access control,
efficient storage and retrieval of data. Same set of issues.
As has been pointed out a couple of times, it's *not* always efficient
to use the filesystem, because the filesystem usually relies on block
sizes. Thus you waste lots of space if your file is < 4k.
As has also been pointed out, locking with network filesystems is dicey
in many cases, and locking mechanisms are not usually cross-platform,
which some of the projects we're talking about require.
Furthermore, access control usually takes the form of uids and posix
permissions, which may not be granular enough. But I suppose you can
use xattrs to fix some of that.
Dan
Once you're talking about "optimized" binary formats,
with hashed
lookups, transactions and locking, you're talking about a database. So
use a database. There's one already built in to your kernel.
> >> Don't get me wrong - GConf has some very bad design flaws (at least
> >> should have used something like Protocol Buffers instead of XML), and
> >> I'm not defending the weird dconf licensing.
> >>
> >> But "let's just use lots of files" is not the answer.
> >
> > So group your keys if too many files is such a problem. You know, like
> > we've been doing for decades. Config files are a Solved Problem,
>
> I don't think so. It's actually a quite hard problem.
Did I say it wasn't a hard problem? It's a hard problem that's already
been solved. Several times over.
> > Everything not greppable, diffable, human readable and editable, should
> > be dragged out in to the street and shot. This is /configuration/ we're
> > talking about.
>
> Nothing prevents one from writing a FUSE layer to expose an actually
> efficient configuration store for the developer/sysadmin experience
> without imposing overhead for the normal case.
Yeah, that's sure keeping it simple. This is the essence of the problem.
All those pushing this "One True Configuration System" thing Just Don't
Get It, "it" being:
http://en.wikipedia.org/wiki/Unix_philosophy
"It's not efficient to do it that way!" and thus "It can't be
plaintext!" are flagrant violations of unix engineering philosophy. Yet
they expect every single piece of unix software in existence to come
running to use it? Good luck with that.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list