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

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

[Warren W. Gay VE3WWG]

Before the flames start, I realize registries have been discussed before WRT Linux/UNIX.
But I
want to suggest an idea that might make a Linux registry more acceptable. I also want to
present
a kernel module measure for those applications that may never support a registry API.

<flame-retardant>

THE CASE FOR A LINUX REGISTRY (again):

UNIX/Linux people are used to working with small text files to configure components.
Additionally,
Plan-9 takes this even further, making just about everything "a file".  The only problem
with this
approach is that there is a need for each application to parse each of these files to load
a
configuration (but this is the easy part, and not really the issue). Many of these files,
use
different formats, which is a pain for those that don't make a living as sysadmins.

To CHANGE a configuration however, you must obviously text edit the file, or edit a file
that is
sourced from a shell script (but many config files do not work this way). No matter how
you slice it,
you must work with a file that your grandmother may never understand or edit.  This
presents
a problem too, when you want to upgrade with an RPM or debian package, etc. To make
matters worse, this is usually done differently on all Linux distributions.

So to satisfy the editor-challenged-user requirement, this now
places the burden on the programmer to provide something else, to
eliminate the need for a sysadmin in the workstation environment. The sysadmin tool must
digest the config file, apply changes, and then write it safely back out. It is doable,
but just how many config files under Linux actually work this way? Not many,
in my experience.

In fact, right now, it seems that Linux now has a split personality at
this level. Some files say "don't edit.. please use **** tool instead", while others
require that the file itself be edited. Well, make up your mind!

While I am no fan of Windows (of any release), the _IDEA_ of a registry is a good one
(note emphasis on the "idea", and not the "implementation"). The registry "idea", allows a
simple program to make configuration changes on behalf of the user. The user is satisfied
with the point and click ease that the program provides, and yet the programmer is able
to provide a reliable configuration program without a major design effort. Other tidbits,
like the most recently used file etc. are very easy to squirrel away. Under Linux, you
either have to waste a lot of file space, or manage it in an inconvenient, and a
system-wide
inconsistent way (each app does it differently).

A BETTER REGISTRY:

A Linux registry can be implemented on top of just about any reasonable file system,
if you want to ignore the "waste factor" for a moment. A file system provides these
advantages:

  - True UNIX file system permissions at each level (ie. security), perhaps
    even with ACLs someday
  - File system integrity (depending upon the file system of course)
  - The ability to mount or share (NFS) it as necessary
  - The ability to modify/view any entry without special registry tools (use
    standard shell tools if you like).
  - The ability to backup and restore the registry, just like any other file
    system.
  - File locking
  - The ability to monitor the space utilization
  - The ability to have multiple registries, where applicable

I recently did a quick survey of the objections to a UNIX registry idea in google
groups, and the objections can be generally classified as:

   - We don't need no stinken corrupted registries like Windoze
   - We don't like special tools like regedit that don't let you see all of the keys etc.
   - We don't like the security mechanisms employed by the Windoze registry(ies)
   - We don't do it that way under UNIX/Linux (*)

I believe all but the last objection, can be overcome with the right implementation.
(*) Time and proof of concept, may melt away the last objection, eventually. ;-)

A FRUGAL FILE SYSTEM

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:

  - where each value is represented by one file (.../key/value is a file)
  - each  key is a directory name
  - each subdirectory is a subkey of the key (key/subkey)

    (or some scheme similar to this)

    I would also suggest that a maximum file size of 8K is probably
   acceptable in a file system like this (larger registry values should
   simply be stored in a file, with perhaps a key pointing to it,
   as a symlink).

For example, if you want to configure a value of the size of an integer (4 bytes),
then usually a file system will allocate 1K (or more) to that file,
wasting 1024 - 4 = 1020 bytes (ls shows the file occupying 4 bytes, but
1020 bytes are physically wasted behind the scenes).

Multiply this by the number of registry values at sizeof(int), and you can
see why this is not a very practical way to implement the idea on just
any file system.

I think something along the lines of the cramfs (without compression) would be quite
suitable for this job. IOW, we need a cramfs that can be mounted Read _AND_ Write,
that was fairly efficient at lookups, allowed frequent updates, and provides a good
fsck for those times where the system crashes (call it something like "FRUGAL").

The FRUGAL file system could be mounted using the loop device to use a
"registry file", or if the user prefers, as another slice of the disk as per usual
for file systems. The file however, may make it easier to grow it, should you
find it running out of space.

HOW ABOUT THEM APPS WITH CONFIG FILES?

Not everyone is going to be eager to migrate apps to use a registry, no matter
how good the registry might be. In fact, some developers may out-and-out say
that they'll "never use no stinkin registry". So what to do?

I think it is possible to provide kernel "bridge" modules for this purpose. For example,
the DHCP server could have a kernel module that takes registry values from
a designated FRUGAL (registry) file system, and then present a ordinary text file
in the proc file system as /proc/etc/dhcpd.conf, based upon all of the known
registry keys as input. So when /proc/etc/dhcpd.conf is opened, the kernel
module can collect all of the registry keys and assemble them into a text
file on the fly, in typical proc file system fashion.

You could also symlink /etc/dhcpd.conf to the /proc/etc/dhcpd.conf, and the
application need not be the wiser. Other major apps could be handled
the same way. Once the first bridge kernel module is written, many others
can be quickly cloned from it.

Once this infrastructure is in place, a number of small pieces of information can
be easily handled in the registry (in the FRUGAL file system). This would make
configuration of servers and workstations much easier than it is now, and it
would make good use of the available disk space. It will still be the "UNIX
way", except that we've now moved parameters to the file level, rather than
grouping all parameters into one file.

THE REGISTRY API:

Once a "frugal" file system is implemented, then a registry API can be developed
to layer registry concepts onto the file system, in a developer convenient way
(in library section 3C).

In this way, the developer is relieved from doing directory searches, defaults,
etc. handling. A value fetch or change could be performed in one (or few)
API calls, rather than many. The idea is to keep the API to a minimum, to
make it easier for developers to provide configuration tools (GUI and otherwise).
We can also learn from the design mistakes made by that other OS ;-)

We need NOT use the same "design" as Windows (no backslashes please!), but
we might want to provide the optional capability to store and retrieve windows
like keys, to accommodate Windows things like Wine. This makes porting
some Windows apps to Linux just a little bit easier.

SO WHAT IS THIS BLATHERING POST ABOUT?

I personally see this registry thing in Linux as an itch that needs scratching. However,
I've neither the time or the developed talent to do a full fledged file system. What
I was hoping to accomplish from this post, is to get people thinking more about the
idea to hopefully find some eager soul to run with it.

Maybe someone out there is itching for an excuse to develop yet another file
system? Now you have an excuse ;-)

While the Windows development environment is an abomination (IMHO),  what
it does have going for it is an easy way to configure and install things on it. At the
same time, I don't like losing control of what's going on. I think a file system
approach with the appropriate API layered on top, provides an acceptable
compromise to both views.

Finally, by implementing a registry this way, all we have done is taken
the file concept FURTHER, down to the paramter level.

Rather than have one file group all parameters (which is done to save space),
we separate each parameter out to its own file. This makes parameters
real easy to query, change and display. To make this practical, we need
a FRUGAL file system to implement a registry.

I am personally growing weary of RPM updates, and debian updates that look
at the config file and say "I can't do anything with this, so I will just rename it
and put the new template one in its place for your editing". Folks this is
not good enough. I think we need a solution to this problem. I think we
can do. Much of the framework is nearly there. Someone just needs to
take the idea, and integrate them.

    Surely, there has got to be a better way!

<begging>

ANY TAKERS?

If you are interested in this idea, and you want discuss ideas privately (perhaps
to avoid flames?), then email me directly at:

    w a r r e n   <at>  c o g e c o . c a

I would really, really, like to see something done for Linux configuration.

(the above email address is designed to avoid spam, since my main mailbox is
getting e-bombed by worms still).

</begging>
</flame-retardent>
-- 
Warren W. Gay
http://home.cogeco.ca/~ve3wwg

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

[Charles Manning]

Warren

I deal with various embedded systems, including Windows CE.

Of the few OS concepts carried over from Windows to WinCE, the registry is 
one.

I can see some merit to the concept of a registry, in theory, in that it 
makes a single configuration system in a single place. This makes 
administration and configuration a bit simpler. However, the concept of a 
single config point is very challenging when one deals with booting etc. 
Windows CE has serious pain there since you need the registry to boot, but 
where do you store the damn thing? WinCE now supports split registries to 
address this.

The Windows registry gets seriously abused too. I've seen it used for 
everything from inter-process communications to implementing error logs etc.

When it comes to newbie users, I don't think they really get any benefit from 
using a registry. How many Windows users use regedit or know there's a 
registry? Nope, they use the service's cute GUI config front-end.  Same for 
your softer Linux user - they just use the GUI sysadm tools and don't have to 
worry where the configs are.

Independently of registries, I think the concept of a frugal fs is a good one 
and likely to be of use to the embedded folk.

-- CHarles

RE: Contraversial: A New FRUGAL File System? Linux Registry (again)?

[Joseph D. Wagner]

I concur with Charles Manning [manningc2@actrix.gen.nz] that the registry is a good idea and would be valuable to Linux, and I unfortunately agree that the registry is too often abused.

I must admit, though, that the idea of using a file system rather than a database as a registry is rather intriguing.  Instead of creating a whole new API for a registry, you can simply use the existing VFS API and treat each file as a registry entry.  However, Access Control Lists (ACL's) would be a must-have before such a file system registry is implemented or else both programs and users alike would surely abuse the registry.

Personally, I think a registry on Linux should be held off until Linux has native support for ACL's.  Trying to build a secure registry based upon the existing file system security architecture (read, write, execute; owner, group, everyone) would simply be too much of a hassle.

Joseph Wagner

> -----Original Message-----
> From: Charles Manning [mailto:manningc2@actrix.gen.nz]
> Sent: Monday, October 27, 2003 12:36 AM
> To: Warren W. Gay VE3WWG; linux-fsdevel@vger.kernel.org
> Subject: Re: Contraversial: A New FRUGAL File System? Linux Registry
> (again)?
> 
> Warren
> 
> I deal with various embedded systems, including Windows CE.
> 
> Of the few OS concepts carried over from Windows to WinCE, the registry is
> one.
> 
> I can see some merit to the concept of a registry, in theory, in that it
> makes a single configuration system in a single place. This makes
> administration and configuration a bit simpler. However, the concept of a
> single config point is very challenging when one deals with booting etc.
> Windows CE has serious pain there since you need the registry to boot, but
> where do you store the damn thing? WinCE now supports split registries to
> address this.
> 
> The Windows registry gets seriously abused too. I've seen it used for
> everything from inter-process communications to implementing error logs
> etc.
> 
> When it comes to newbie users, I don't think they really get any benefit
> from
> using a registry. How many Windows users use regedit or know there's a
> registry? Nope, they use the service's cute GUI config front-end.  Same
> for
> your softer Linux user - they just use the GUI sysadm tools and don't have
> to
> worry where the configs are.
> 
> Independently of registries, I think the concept of a frugal fs is a good
> one
> and likely to be of use to the embedded folk.
> 
> -- CHarles
> 
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Charles Manning]

On Monday 27 October 2003 20:10, Joseph D. Wagner wrote:
> I concur with Charles Manning [manningc2@actrix.gen.nz] that the registry
> is a good idea and would be valuable to Linux, and I unfortunately agree
> that the registry is too often abused.

Hang on Joseph! I said I thought that the idea had merit **in theory**. In 
practice I'm not sure that the registry is such a fantastic idea.

I think though that a frugal file system could have some uses independent of 
the registry concept.

-- CHarles

RE: Contraversial: A New FRUGAL File System? Linux Registry (again)?

[Joseph D. Wagner]

Our disagreement is moot because I'm not even going to look at the idea now.  I'm waiting for native ACL (Access Control List) support.

> -----Original Message-----
> From: Charles Manning [mailto:manningc2@actrix.gen.nz]
> Sent: Monday, October 27, 2003 1:26 AM
> To: Joseph D. Wagner; 'Warren W. Gay VE3WWG'; linux-
> fsdevel@vger.kernel.org
> Subject: Re: Contraversial: A New FRUGAL File System? Linux Registry
> (again)?
> 
> On Monday 27 October 2003 20:10, Joseph D. Wagner wrote:
> > I concur with Charles Manning [manningc2@actrix.gen.nz] that the
> registry
> > is a good idea and would be valuable to Linux, and I unfortunately agree
> > that the registry is too often abused.
> 
> Hang on Joseph! I said I thought that the idea had merit **in theory**. In
> practice I'm not sure that the registry is such a fantastic idea.
> 
> I think though that a frugal file system could have some uses independent
> of
> the registry concept.
> 
> -- CHarles

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

[Bryan Henderson]

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.  The fact that individual subystems are 
isolated to individual configuration files is another one.

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

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.

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

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

--
Bryan Henderson                          IBM Almaden Research Center
San Jose CA                              Filesystems

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

[Warren W. Gay VE3WWG]

"Charles Manning" <manningc2@actrix.gen.nz> wrote in message
news:20031027063015.98B1332C6D@desire.actrix.co.nz...
> Warren
>
> I deal with various embedded systems, including Windows CE.
>
> Of the few OS concepts carried over from Windows to WinCE, the registry is
> one.
>
> I can see some merit to the concept of a registry, in theory, in that it
> makes a single configuration system in a single place.

Yes, and no.. in *theory*, it need not necessarily be *one* place, but  no
matter for this discussion...

> This makes
> administration and configuration a bit simpler. However, the concept of a
> single config point is very challenging when one deals with booting etc.
> Windows CE has serious pain there since you need the registry to boot, but
> where do you store the damn thing? WinCE now supports split registries to
> address this.

I personally don't see too much of a problem here. For one, the boot
process is a one time thing (relatively speaking, at least ;-)   For the
boot process, you don't need a registry at boot time, since you could take
registry values and assemble them into some convenient file/location
to be used at boot time (compiled if you will, in lilo fashion).

> The Windows registry gets seriously abused too.

That is not the registry's fault ;-)  A file system can just as easily be abused.

> I've seen it used for
> everything from inter-process communications to implementing error logs etc.

Well, ya know, a sports car isn't bad, just because a teenager is
able to wrap it around telephone poles.  If you are given the keys
to the car, you must accept some level of responsibility for how it
is used. The technology itself is not to blame here.

Look at the windows file system. Your files are saved all over the place,
at least by default.

It appears that MS are now moving towards putting stuff in an applications
directory, but historically, every app has had its own place to store your files
by default. Many applications return to their own custom directories the
next time the app starts, or with some of them, every time the file
save dialog box is popped up. Compare this with the POSIX design
of saving user files in the users home directory.

But these problems are _not_ the fault of a hierarchical file system.

The fact that the registry is abused is not the fault of the registry
beyond perhaps the way permissions are handed out. And who
designed the permission structure?

If you want to keep all user keys out of the system directory, prevent it
with a proper permission scheme.  Force user settings to another registry
file system (or file) perhaps, designed for the purpose. If they abuse that,
then they've just wrapped their own sports car around the pole. 8-)

> When it comes to newbie users, I don't think they really get any benefit from
> using a registry. How many Windows users use regedit or know there's a
> registry?

You're right, they don't.  I bring it up, because many sysadmin types will
insist on direct access to the values (the user doesn't want it).

> Nope, they use the service's cute GUI config front-end.  Same for
> your softer Linux user - they just use the GUI sysadm tools and don't have to
> worry where the configs are.

Yes. The user uses the GUI config tool. But GUI config tools are
difficult on the Linux side, because they have to parse a text file (a la
win.ini style, in so many ways), and then write it back out again. It
didn't take long for M$ to abandon *.ini files, for obvious reasons.

OK, here is a problem for you on the Linux side.  You want to install
some Open Sourced package named XYZZY on your Linux machine.
But, it needs my Ada (Ada95) software package (library) to build
it from sources. But you don't program in Ada, and could care less
about that language, but you insist on building everything from sources
(maybe you need to, to get the most performance on your box).

Now here is the problem _I_ face, writing that Ada package. How
do I determine which gcc compiler to use? You may have the latest
GCC collection that implements gcc with Ada support, but it is
slightly busted in the Ada sense (which pretty much sums up the
present state). You may also have the gnatmake command installed,
which will invoke its own version of gcc. How do I tell which gcc
to use?  Do I trust your current PATH? What if it is not in the PATH
for root, when you invoke an install? What if you have other versions
of gcc, that are meant to be used? Or not used? Are they to be searched
out, or assumed? Where should my Ada source package specs go? They
are like C include files, except there is no standard location for them.

If my install script says that you don't have GNAT installed, you might
say, well yes I do, ya dumb script -- ya just don't know where to
find it.

If on the other hand, GNAT (the Ada compiler) had access to a
registry like it does in win32 installs, it can register the answers to
these things in a standard sort of way. Then I can answer these
questions (query these things) at install time, without even trying,
like I presently can  do under the win32 install process. Same
package, but the Linux install process is a nightmare, while the
win32 install process is dead simple.

So the basic picture is that:

   - Windows installs are smooth
   - Linux installs require guesswork and often require user
      manual intervention

> Independently of registries, I think the concept of a frugal fs is a good one
> and likely to be of use to the embedded folk.
>
> -- CHarles

Apparently, this is not necessary. Someone else has already done the
work: Reiserfs! Thanks to Bryan Henderson  for pointing this out.

All I am trying to do here, is to get people thinking along new lines.

The idea of the registry is not wrong. Let's just look at  ways to
learn from M$ mistakes. I think the biggest mistake is to write
the idea off, just because it "wasn't invented here".
-- 
Warren W. Gay
http://home.cogeco.ca/~ve3wwg

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

[Warren W. Gay VE3WWG]

"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

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

[Warren W. Gay VE3WWG]

"Joseph D. Wagner" <theman@josephdwagner.info> wrote in message
news:003901c39c59$6248dab0$0201a8c0@joe...
> I concur with Charles Manning [manningc2@actrix.gen.nz] that
> the registry is a good idea and would be valuable to Linux, and I
> unfortunately agree that the registry is too often abused.

I have said elsewhere in this thread, that this is not the technology's
fault. If you want to keep user entries out of a system registry, then
set the permissions up that way. M$ does a poor job of laying
out security in both the registry and their file systems (ie. NTFS).

But neither the hierarchical file system, nor the registry is to be
blamed for the abuses!

> I must admit, though, that the idea of using a file system rather
> than a database as a registry is rather intriguing.  Instead of creating
> a whole new API for a registry, you can simply use the existing VFS
> API and treat each file as a registry entry.

Bryan Henderson suggested that the Reiserfs would be a good choice,
and based upon what I have read today about it, it would seem so.
No need to write a FRUGAL file system, either.

Apparently, Reiserfs also provides a special lighter weight API too,
to avoid the overhead of a full open/read/write/close protocol. A
registry API could carefully wrap that, for a little more convenience.

Additionally, Reiser4 permits plugins that can assemble registry
entries (small files) into a common file "view". This would be
a simpler way to implement my idea of a /proc/etc/file.conf
file. These "views" can even be edited directly by a text
editor, and then affect the individual registry entries (small
files), upon saving (assuming that the permissions on all of the
registry entries (small files), permitted that save).

Reiserfs also provides a "transaction" oriented approach, which is nice
to have in a registry change scenario.

> However, Access Control Lists (ACL's) would be a must-have before
> such a file system registry is implemented or else both programs and
> users alike would surely abuse the registry.

I agree that ACL support would be a good thing for flexibility, but I
fail to see how it would be a prerequisite. You don't exactly have
users abusing /etc where many config entries are stored today.

The registry when properly secured, need not be any worse than
/etc access.

In fact, as I suggested elsewhere, you could supply a 2nd registry
file system that was for general user use. They can abuse
themselves until they go blind, but at least they'd not interfere with
the system configuration that way. Registry disk space can be
better limited as well.

> Personally, I think a registry on Linux should be held off until
> Linux has native support for ACL's.  Trying to build a secure
> registry based upon the existing file system security architecture
> (read, write, execute; owner, group, everyone) would simply
> be too much of a hassle.
>
> Joseph Wagner

I do agree that ACLs provide flexibility in exceptional
cases. UNIX file systems have been used for decades successfully
without ACLs, so I believe that a file system based registry need
not necessarily be any different. ACLs would however, open new
possibilities for exceptions to the rule, cases.
-- 
Warren W. Gay
http://home.cogeco.ca/~ve3wwg

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

[Warren W. Gay VE3WWG]

"Charles Manning" <manningc2@actrix.gen.nz> wrote in message
news:20031027071956.98995719C@blood.actrix.co.nz...
> On Monday 27 October 2003 20:10, Joseph D. Wagner wrote:
> > I concur with Charles Manning [manningc2@actrix.gen.nz] that the registry
> > is a good idea and would be valuable to Linux, and I unfortunately agree
> > that the registry is too often abused.
>
> Hang on Joseph! I said I thought that the idea had merit **in theory**. In
> practice I'm not sure that the registry is such a fantastic idea.
>
> I think though that a frugal file system could have some uses independent of
> the registry concept.


Think Reiserfs. I think that might be the ticket.

But if you think the *theory* of a registry is OK, then let's work on that. How
do we go from theory to practice in an acceptable way?

-- 
Warren W. Gay
http://home.cogeco.ca/~ve3wwg

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

[Ingo Oeser]

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

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

[Matthew Wilcox]

Could this wankfes^W discussion take place somewhere other than
linux-fsdevel?  Thanks.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

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

[Ian Kent]

On Tue, 28 Oct 2003, Ingo Oeser wrote:

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

Software upgrades don't work well because of a registry. They work well 
because the sweat that a developer puts into getting it right. It's 
just as easy to get it wrong under Windows. I haven't worked with the 
installer packages under Windows for a long time but the little I did I 
found that it wasn't easy or satisfying. Not to mention those 'odd 
problems that just won't go away' that could only be solved by spending 
hours trauling through the registry, deleting keys and praying it will 
work and not break anything else.

Quality install systems are platform and OS and configuration store 
independent.

-- 

   ,-._|\    Ian Kent
  /      \   Perth, Western Australia
  *_.--._/   E-mail: raven@themaw.net
        v    Web: http://themaw.net/

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

[Bryan Henderson]

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

The progression in the Windows world wasn't because software got more 
complicated -- it was because users got less sophisticated and more 
demanding.  If Linux is to progress to where Windows is, then I agree that 
anything like .ini files has to go.  But it would be wrong for Linux to 
progress to where Windows is.  Windows is already there.  In moving from 
.ini files to a registry, Windows moved ahead in certain areas and behind 
in others.  Folks who benefitted from .ini files in DOS, then moved from 
Windows to Linux.

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

You misinterpreted "isolated to."  It doesn't mean all of subsystem A's 
parameters are in a single file; it means none of them are in the same 
file as subsystem B's parameters.  A directory of configuration files for 
a single subsystem is fine with me.  If they're files I can process with 
ordinary text tools.

>> 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.
>
>but there is no reason whatsoever that you might not both use 
>the same O/S some day

Yes, some day -- when we find the technology.  We haven't found it yet. In 
particular, we haven't found a way to do a registry that is as good as 
Windows for her and as good as Unix for me.

Putting together the various arguments and comments people have made in 
this thread, it sounds to me like the best place for Linux configuration 
to move is toward splitting monolithic configuration files into a 
directory structure and going toward some standard language for them, 
which is text-based and both machine and human friendly.  I don't know if 
the word "registry" applies to that.  The only thing "registry" means to 
me is that thing I hate on Windows.

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

[Brian Beattie]

On Tue, 2003-10-28 at 14:18, Bryan Henderson wrote:
> >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.
> 
> The progression in the Windows world wasn't because software got more 
> complicated -- it was because users got less sophisticated and more 
> demanding.  If Linux is to progress to where Windows is, then I agree that 
> anything like .ini files has to go.  But it would be wrong for Linux to 
> progress to where Windows is.  Windows is already there.  In moving from 
> .ini files to a registry, Windows moved ahead in certain areas and behind 
> in others.  Folks who benefitted from .ini files in DOS, then moved from 
> Windows to Linux.

Please excuse me, I'm an old fart and remember the days even before ini
files, though never fooled much with MS software.  I've always heard
that there was some problem with ini files, and that for this reason MS
went with the registry, but I was never too clear what the problem, I
sort of had the impression that it was lazy and incompetent Windows
programmers who could not manage their own configuration files, but
maybe that was just my own bias showing.

Can somebody tell be just what the problem with ini files was, that the
registry was supposed to solve?

-- 
Brian Beattie            | Experienced kernel hacker/embedded systems
beattie@beattie-home.net | programmer, direct or contract, short or
www.beattie-home.net     | long term, available immediately.

"Honor isn't about making the right choices.
It's about dealing with the consequences." -- Midori Koto