From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Warren W. Gay VE3WWG" Subject: Re: Contraversial: A New FRUGAL File System? Linux Registry (again)? Date: Mon, 27 Oct 2003 22:05:06 -0500 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: References: <20031027063015.98B1332C6D@desire.actrix.co.nz> Return-path: Received: from main.gmane.org ([80.91.224.249]:2734 "EHLO main.gmane.org") by vger.kernel.org with ESMTP id S263834AbTJ1DEm (ORCPT ); Mon, 27 Oct 2003 22:04:42 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AEK9v-0006RM-00 for ; Tue, 28 Oct 2003 04:04:39 +0100 To: linux-fsdevel@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org "Charles Manning" 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