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

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

"Bryan Henderson" <hbryan@us.ibm.com> wrote in message
news:OFDF4C9C01.1FAC16C7-ON87256DCC.00600B7E-88256DCC.00613563@us.ibm.com...
> I regard the fact that I can manipulate system configurations with
> general-purpose text processing tools (e.g. emacs) to be one of the major
> advantages of Unix over Windows.

M$ tried this with *.ini files. They were text file friendly, but got unwieldy
pretty darn quick, when you started to automate other configuration data
in them. The same problem will progressively occur under Linux/UNIX
as software gets more complicated each year.

But what I really hate doing most, is doing things twice!

                     Here is a recent example:

I did a debian upgrade of my X-Window software. The upgrade went
fine, replaced files galore etc., and I trundled along for weeks until I
had a reason to reboot one fine day. I was in a hurry and guess what?

My X-Window system would not start anymore.

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...

Did anyone write a program to do this migration? No. Too much
work.

Now I had to not only merge my changes from the original
stupid file, but I had to adjust to config file changes that I was
uncertain about. There were obvious changes, and others
were less, obvious, but required some experimentation on my
part. This was poor use of my time, which I am very short of.

Now this is not a happy user experience.  I have more important
things to do as a developer, than to play "I'm a sysadmin". My
focus is on writing software, not tweaking it. Yet I need to keep
my system more or less up to date.

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.

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.

> The fact that individual subystems are
> isolated to individual configuration files is another one.

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).

> The fact that these individual files all have their own private languages
> is a big drawback, but a good bargain for the aforementioned advantages.

The only reason that these parameters are grouped in one file is that
there is too much waste to separate them into their own little files,
and for editor convenience. Otherwise, things would be split out
for ease of automated configuration instead. That is why RedHat and
others extract many parameters that are sourced into shell scripts,
into their own little files. Else they would just remain in one big
script file instead.

> But let me be clear on where I'm coming from:  I would not expect my
> grandmother to use my computer, and I would not want to use hers.

You don't need to use the same physical machine, but there is no
reason whatsoever that you might not both use the same O/S some
day. I see a day coming in the future where operating systems
become a commodity that nobody wants to dedicate resources
to (look at how Linux is displacing proprietary UNIX).  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. They want the computer
to work for them, not the other way round.

> >Some files say "don't edit.. please use **** tool instead"
>
> I rather like that compromise.  I often edit these files instead of using
> the **** tool, after I get comfortable with that subsystem.  I appreciate
> the option.  (And even when I don't modify the file, I certainly
> appreciate being able to look at it, move it, back it up, etc.).

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

> >The real problem with implementing a Linux registry on top of a file
> system
> >is that you need a file system that won't waste so much space for
> >each tiny registry value:
>
> Isn't this one of the goals of Reiserfs?  Making tiny files efficient so
> you can break what is traditionally one file into a directory full of
> files?

Thank-you, this is a real good idea. I must admit that I didn't know much
about this file system until you mentioned it. It appears to have all of the
right ingredients for the job. I'll be checking it out. ;-)
-- 
Warren W. Gay
http://home.cogeco.ca/~ve3wwg