Re: Controversial: A New FRUGAL File System? Linux Registry (again)?

[Ingo Oeser <ioe-lkml@rameria.de>]

Hi,

On Tuesday 28 October 2003 04:31, Warren W. Gay VE3WWG wrote:
> Now, under time pressure at this point, I had to root around, and
> find out why. I eventually traced it to the fact that the software
> upgrade didn't know what to do with the last X-Window
> configuration that I fought hard to get right last time. It had taken the
> simple approach of renaming XF86Cofnig-4 to XF86Config-4.bak,
> and installing the most recent version of the sample config. Well,
> at least it didn't throw it away...

Hmm, I'm usally offered 4 options in debian:
	1) take the maintainers version
	2) take my version
	3) view a diff of them
	4) get a shell and examine the situation

You finally must decide what you take, but this conflict is resolvable
in 3 steps:

1) View the difference and check, what the maintainer want to be done here.
2) Edit my own version to react on the changes wanted by the maintainer.
3) choose "take my version"

The exact dialog can be read up in the debian sources somewhere.

So your registry is not needed you resolve that problem on a debian
system and it would be rather contra productive for me to NOT have these
4 options debian offers me here.

> A registry would have made it very simple for a migration program
> to keep/migrate the settings I already had. But because nobody
> wants to expend the effort on a parse and re-write a config
> file program, it is NEVER done. IOW, the config file is too
> hard to work with.

Nope. The Windows-approach is usally "don't trust the user and overwrite
it's data with what we think is better"

> Yet, these kinds of upgrades are successfully done in the
> win32 environment, every day. Even my grandmother could
> have done it, were there an equivalent upgrade on the win32
> side.

You haven't used much windows software, I guess. Neither do I, but I had
to repair the system afterwards and had to warn the users that their
configuration is lost in this and that little program they need, if they
upgrade.

I don't want this to happen on MY machine.

> I fail to see the difference here between parameters gathered into one
> file, vs those same parameters gathered into one directory.  The only
> difference is that you want to see them together, in your favourite editor
> (I like emacs too, BTW). Fortunately for people like you, the Reiserfs
> can assemble registry pieces (files) into a text file "view" for editing,
> if you want (via a plugin).

That's useful. A common parser and a common config file format would
solve all this quite nicely. *.ini is not sufficient, because you cannot
express grammar and nesting with that. XML is too bloated for the human eye.

I would like sth. like void C functions for that. So basically:

<vars> ::= <var> \n <vars> | <empty>
<var> ::= <name> "=" <value_or_compound>
<value_or_compond> ::= <value> | <compound>
<compound> ::= '(' <vars> ')'

<value> ::= <text> | <filename> 
                   | <time> | <timediff> 
		   | <binary_scaled_int>
		   | <SI_scaled_float>
		   | <ref>

<ref> ::= "@" <name>

and so on...

> It is not totally inconceivable that even that the Windows O/S could
> be replaced with Linux underneath, while M$ continues to sell
> applications to run on top of it. After all, it is the applications
> that we want. O/S work may be fun for the some, but many users really
> just don't care how it works.

With M$ applications come M$ standards. So not everybody is happy with
that and not everyone wants their applications.

> They want the computer to work for them, not the other way round.

Right. That's why I don't want applications dictating or even suggesting
or guiding me what to do next. I want a toolbox and want to combine
the tools from different vendors.

> A file system based registry will give you all of the same options.

No. It will impose ordering on you. Look at the windows registry.
There is a big difference on what the user things belongs together and
what the programmer thinks about ordering. Esp. when a program evolves.

Regards

Ingo Oeser