Re: Module proposal: dconf

[Alan Cox <alan lxorguk ukuu org uk>]

> - FS are usually implemented very carefully. They tend to be part of
> kernel. On the other hand desktop applications are designed much more
> 'speedy'. Sometimes application hangs (much more frequent then kernel
> locks IMHO), sometimes it crashes.

Desktop application software mostly sucks. I wouldn't argue with that,
but the libraries used at the low level are mostly good clean code.

> - FS have much better support of tools which recover the data. Well -
> you cannot edit by XML editor but both FAT and EXT2/3/4 have numerous
> tools that recovers data - even less popular systems like reiserfs have
> them. I haven't seen them for many application binary format.

So write one. The format is visible, the code is open source. You should
just need xml2vomit and vomit2xml or whatever format data you use.

> - The more common code the more profitable optimalization is. If the
> format is read once at startup it makes much more sense to have it more
> readable then fast. On the other hand if it is used constantly...

That argument is garbage. It's one reason why Gnome takes forever to start
up. As a normal use you regularly start applications and desktops, you
almost never go and emacs the XML file.

Take 20,000 distro Gnome users, what percentage of them do you think have
ever hand edited their configuration, what percentage do you think have
ever used things like gconftool. For that matter what percentage of
normal users do you think even understand the question "Have you ever
hand edited your gconf database"

They all start the desktop up, they all bitch about it taking forever.

> looking through it is cheap as it is already in random access memory.
> Since even cache operates on virtual memory as long as block is
> continuous it makes practically no difference in speed.

Reality check. On a modern hard disk a good rule of thumb is that reading
512Kbytes of data costs as much as a single sector read. So you want all
your metadata in a single linear file loaded once, in order. Now whether
that is something looking like rot13 encoded vomit, beautifully spaced
and formatted XML or a database format is less important because the
rotational latency and seek latency of the disk dominate any processing
time unless your data format is extremely bogus.

> - FS are rarely compressed. Text-based formats are much compressable and
> backup of them would take much less space.

The same *information* should compress to the same size irrespective of
the input. Thats a mathematical theoretical case but reality isn't far off
providing any padding is consistent. You don't want to compress critical
backup data anyway because it means a bit error on the backup media costs
you vastly more data.

The only sense by which text compresses is better is the "because it was
larger and more wasteful to begin with" sense.

Shrug.. pluggable back ends would be nice anyway. I'd rather have my base
preferences in hesiod