[Registry] Re: LinuxRegistry in Freedesktop & KDE

[Dave Cridland [Home]]

On Sun, 2004-04-18 at 19:08, Daniel M. Lambea wrote:
>   About current knowledge, we must admit that any kind of user which is
> able to read and change XF86Config by hand would have not a single
> problem in going to /etc/registry/whatever/key/ and edit the keys
> inside. The current knowledge is not lost, since currently any admin has
> lots more knowledge than necessary to edit a file. Also, take into

Yes, the key piece of that knowledge being which file to edit, and what
changes to make. A lot of that knowledge is actually accessed by people
when they see the whole file they're editing - I know I look for virtual
hosts in Apache that match what I need to provide, and copy them
wholesale. I don't know the bytes or indeed strings I'm looking for, in
some cases, I just flick through until I spot it. Human brains are odd
things, and you'd be surprised how much knowledge is only really
triggered when people are looking at something familiar.

I think you'll find that a huge amount of retraining is needed. And
don't think it's a one off job, either - they'll be a constant flow of
admins from Solaris or HP-UX, who'll be surprisingly lost in a sea of
tiny text files.

> account that we could use command line tools to do that, apart from
> other UI-oriented utilities we might have (curses-based, KDE-based,
> GNOME-based, whatever). A simple key editing tool is as good editing
> XFree's configuration as editing the Apache configuration.

Entirely orthogonal to the problem at hand, though false anyway.

The majority of sysadmins I know would be perfectly happy to use some
form of cosy UI to do their day to day work, as long as they can hit the
real files when things go wrong.

The problem is that each key has semantics - a simple key editing tool
is no better than vi, and quite possibly worse, given the lack of
contextual information presented. The key editing tool must know the
semantics of the key it's editing.

>   And we code not only for end-user usability. What about system
> administration? Isn't it useful to share desktop background's
> preferences, keyboard layout prefs, mouse prefs? And then we could speak
> about file formats, and the tons of code needed to parse every
> configuration file in every piece of unix software.

Oh dear.

Firstly, it's trivial to code a parser for a simple key: value formatted
config file. Secondly, that code exists in those apps, and is very well
tested. Thirdly, the newer 'desktop' apps handle all this functionality
already, and do it through an API, so the code only exists once.

Having KDE and Gnome, for instance, sharing preferences is indeed a
noble goal, and one I'd love to see. It also has nothing to do with LR.

>   "Incredibly lack of efficiency" in needed code, in system administration
> learning-curve, and, of course, in a wrong combination of hardware and
> software chosen by the user. Gaining 1 millisec in reading a complete
> configuration file is poor benefit compared to:

Ah, so it's the user's fault? Glad we cleared that up, then.

>  * Ability to alter parts of the configuration file, while keeping the    
>   rest untouched. How many disk accesses we save now? And memory
> consumption?

Well, my guess is that a typical configuration file is less than a
couple of blocks, so, erm, LR makes a net loss there. I could be wrong,
but I strongly suspect that LR will take more in terms of the system's
cache, disk space, and head movement. Laying down one single block is
the same speed, no matter whether you're writing 4k of data or 4 bytes,
as I understand things.

>  * Ability to read just-what-we-want, instead of reading *everything*.
> (Why should I parse the complete Apache configuration file, just to tell
> the user the names of the virtual hosts?)

Actually, you don't need to parse the Apache config file to do that. You
just need to write it, that's all. GConf, KConfig, ACAP, LDAP - all
these things can store the apache config for you, leaving the config
files intact for httpd to use, and allowing them to be used no matter
whether GConf is running or not. An experienced sysadmin with *no*
knowledge of any of these config systems can even deal with it if things
go wrong, and have the configuration system reparse the file.

>  * Ability to read on demand, instead of preventive reading. (Why should I
> parse the complete Apache configuration file, just for the user to end up
> changing only the admin's email address?)

See above.

Also:

1) You'll need to read, and parse, a significant number of files simply
that change that specific datum in a way that's useful to the user, with
LR.

2) You'll need to search through multiple directories, too, with LR.

>  * Ease in versioning. File format changes are evil.

Versioning what? I'm not sure I follow you here.

File format changes are indeed evil, and you're proposing one.

>   "Extreme waste of disk space" has not the same weight as ten years
> before. Hardware gets cheaper as we write. Harddrives from nowadays are
> duplicating their capacity vertiginously. Not that I'm saying we want to
> waste space just because we have it. But the reasons above are good
> enough. It is like storing just two digits for the year field, to avoid
> wasting space in the other two digits.

I have 1078 lines in my httpd.conf. These include copious comments to
remind me what I was doing. On the assumption that there's 500 lines of
actual configuration data, and that LR stores them one file per line,
that's around 1M of disk to store something currently taking (including
the comments) 35K. That's considerably more bloat than Microsoft are
capable of with Word. That's ridiculous.

Let's look at it another way - a typical virtual host in Apache takes up
a fraction of a block, but contains somewhere around 10 lines,
typically. Assuming each line is a single key or directory, then you've
takes up 40k of disk to store ~250 bytes of data. See? We have passed
ridiculous, and moved into impressive.

I think it's possible to store it less efficiently, if you really work
at it, but without actually cheating and storing redundant data, or
splitting up each value so you only store one byte per file, I can't
think of a way. Finally, we move into Extreme.

I think you missed the original commenter's use of the word "extreme".
If wasting disk space were a dangerous, yet hyped-up sport, LR would
have a string of cult websites in garish colours, and feature
prominently on the cover of glossy, expensive magazines dedicated to
pointlessly wasting disk space, including reader's letters with titles
like "75dpi PNG to 1200dpi TIFF - Far out!".

This is not, at all, like the Y2K issue. The Y2K issue was saving 2
bytes of storage at a time when storage was very expensive, and the
software lasting for twenty years without anyone realizing. Those
'saved' two bytes caused problems when the two bytes of missing
information because useful again. I don't see the connection at all.

> >>  Most of these keys
> >> are going to be small numbers or very short strings.  LR causes you to
> >> waste up to 4K or more of diskspace for each of those.  Small system
> >> friendly, eh? *snort*
> 
>   There are other alternatives for filesystems that are much more optimal
> for small files, without introducing sensitive impact on bigger ones.
> Changing the filesystem is not a task to do every week, I know. But
> introducing the LR has not to be done today, is it? We can migrate as
> slowly as needed. The final benefit deserves it. After some years, we
> could end up in a better system, using better filesystems, and a common
> configuration architecture.

So you're saying that because LR performs badly and wastefully, it's the
system's fault, so change the system? Wow. That's cool. I wish I could
say stuff like that with a straight face.

I have to say, I'm still not clear on what LR actually gains us.

I see it gains a uniform method for setting a key, but given that the
semantics of the key are undefined, the key must, by inference, only be
set by an application, or human, which is fully informed.

On the downsides, there's either massive filesystem changes (extremely
difficult for legacy systems), or massive disk usage wasting (I for one
may have a very large disk, but the partition mounted on / is very tiny
indeed), and there's certainly impact on every application you wish to
control with it.

And all just to get a uniform configuration system for boot time?

Wow.

I'm a configuration system junkie, and people can, and do, accuse me of
being on crack for writing servers for 7 year old protocols nobody uses,
but this is really impressive. I bow down to your greatness. I store all
my data in memory all the time, and I may write the whole lot at once to
a single bloated XML file whenever anyone writes, and suddenly, I feel
quite sensible doing so. ;-)

Dave.