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@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. 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
