Re: Status of gconf -> dconf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2009-02-24 at 12:30 -0500, Colin Walters wrote:
> 2009/2/23 Callum Lerwick <seg@xxxxxxxxxx>:
> >
> > 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.

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.

Attachment: signature.asc
Description: This is a digitally signed message part

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux