LinuxRegistry in Freedesktop & KDE

[Sean Middleditch]

On Sat, 2004-04-17 at 02:29 -0400, Duncan Mac-Vicar Prett wrote:

> > 'system' in question)?  It solves no issues, just breaks existing config
> > files, replaces them with different ones which have a different set of
> > issues.
> 
> can you explain us why does it breaks something?

Because it requires people to recode for absolutely no real-world gain
in features or ease or use.  In fact, it's a disservice to users,
because it would cause all existing knowledge and tools to become
invalidated.  With no other gain in usability in the new config system,
that's bloody pointless.

> 
> > I could very well push ve-config for the same purpose.  I can then write a
> > tool to view trees of such .ini style files that ve-config uses as a GUI
> > and then name it something like ViciousRegistry.  And I bet it would
> > actually perform better on most systems and would have less issues. 
> 
> Don't know what ve-config is. But I am not pushing LR for an specific purpose, 
> I just find it cool to have a common ay to store config,  and I haven't found 
> another solution (simple, no-dependencies, plain text files). So I am pushing 
> it just to hear opinions and make a discussion about it. Why? I dont want to 
> see someday FD.org proclamating GConf as a FD cfg standard and telling myself 
> "why didn't I participate in the discussion?" 

GConf isn't and never will be a standard.  Even the GConf developers
know better than that.  ~,^  LR just isn't a solution to any real
problem.  It solves absolutely nothing.  Especially when you're asking
for "no dependency" config files when LR itself *is* a dependency beyond
what all existing apps already have...  Those apps could easily have
used a one file per key structure before, that's very little code to
write.  There's a *reason* they didn't.

Aside from the incredibly lack of efficiency in read/write speed caused
by using those separate files, there's also the extreme wasted disk
space.  Each and every file takes up a minimum amount of size (usually
something like 2K or 4K or something) on most FS.  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*

> 
> > "Actually, the (inevitable) adoption of Reiser4 filesystem will eliminate
> >  this issue."
> > So this is a system which will semi-work ok on some linux systems which
> > happen to use the proper file system and you are thinking it will get
> > adopted as a standard for apps like apache (or just about any other free
> > software server or desktop app) which runs on many systems that don't even
> > support said filesystem.
> 
> You are talking about performance problems without measuring them first. The 
> author is assuming it performs bad, but perhaps it doesn't. You talk about 
> other solutions being better because they are human editable, but you didn't 
> even noticed LR is human readable too.

No, we know it does. File system access is slow.  Even when cached, it's
slower than parsing a single file.  This has been proved over and over
again since the creation of file-based storage systems.

-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.