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

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

"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