[Registry] Re: LinuxRegistry in Freedesktop & KDE

[Sean Middleditch]

On Wed, 2004-04-21 at 10:27, Avi Alkalay wrote:
> > I'm going to have to agree with George here. A single file is much
> > easier for discovery of keys, not to mention the easing of names. 
> 
> Besides the issues, it is also better for security and symbolic links.

Any system based solely on the file system is bad for security.  With
it, we're limited to the very ineffective UNIX file permissions.  In
order to assign different keys to be writable to different users (staff
members and such that I don't want to give a universal-super-power root
password to) I'd have to create a UNIX group for each set of files/keys
(which isn't feasible given the limits on groups most systems have) or
use POSIX ACLs which are not universally available.

A daemon can provide more powerful access control (by authenticating the
user connecting to the daemon and using built in ACL policy geared
specifically for configuration management), as well as enforce logging
of key changes and fix race conditions on keys that LR can't handle
(which are both major security issues).  The daemon also means that the
configuration tools themselves do not need to run as root, which is very
important given that graphics toolkits generally aren't that secure (way
too much code that's highly complex in nature).

All of these issues are present with current file-based configuration
systems, yes, but if you're going to make people switch APIs and loose
all existing experience and knowledge regarding configuration their
systems, perhaps you should try to fix these real problems (among the
others we've raised already, like network-shared configuration, change
notification, value/type constraints, etc.) and not just worry about
something as trivial and irrelevant as file format...

>    bash# rg vi system/sw/XFree
> 
> And vi will pop with an XML vision of your keys. Then you'll change and
> save it, and rg will find what you changed, and apply it.

That's not much better than one file per key.  If you're going to add
hacks for linear editing of keys, provide it in a format users can
safely, easily, and efficiently edit, not a format intended for machine
parsing.  Most apps that have introduced XML config files have gotten a
*lot* of flak from users because it is such an incredible pain to work
with compared to other file formats, like those you're trying to get rid
of.

> 
> 
> > The final time, application startup, is where the real meat and potatoes
> > of config files is, and this is where a single file wins. Take an
> > application like Apache or Xfree, split each option and section up into
> > a single key per file, and you are looking at 100-300+ files to read in,
> > which will take longer and be less efficient than a single relatively
> > small file with multiple keys per file. Winner, multiple keys per file.
> 
> Yeah, for speed 1 file wins. But it happens only once per year (for
> Apache for example).

That's great for Apache.  You're not pushing LR for Apache, you're
pushing it for the entire system.  You can't assume that since it's not
bad for one daemon in one use case that it's therefor not bad for the
entire system.

And boot up time *does* matter.  Users don't want to wait for their
machine to boot.  Many desktops (and especially laptops) need to boot up
a lot more than once per 6 months, often many times per day, and these
systems have slower disks than most servers.  Laptops especially need to
avoid file system traffic as much as possible because spinning up the
disk (or keeping it spinning for longer than necessary) slaughters
battery life.  The less seeking and traversal the disk has to do, the
better.
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.