From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Warren W. Gay VE3WWG" Subject: Re: Controversial: A New FRUGAL File System? Linux Registry (again)? Date: Mon, 27 Oct 2003 22:31:20 -0500 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: References: Return-path: Received: from main.gmane.org ([80.91.224.249]:9646 "EHLO main.gmane.org") by vger.kernel.org with ESMTP id S263793AbTJ1Daz (ORCPT ); Mon, 27 Oct 2003 22:30:55 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AEKZK-0006eo-00 for ; Tue, 28 Oct 2003 04:30:54 +0100 To: linux-fsdevel@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org "Bryan Henderson" 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