My idea along that line would be something like PAM does today. That is a library that handles the calls for security and eliminated the fact of re-compiling code just to change from one security type to another. I see no reason that we could not get at least the largest majority of configuration information into a library like that. Then we could have any type of "files" that we want depending on the need. Like a LDAP database for networks and text files for local machines. Since the program would only need to make the calls to the library it would not care what kind of format the data is stored in.
My only concern for this is performance. I like running Linux on smaller hardware. It is very beneficial to me in my job as well as in the workplace. So, the first thing I think we need to work on is a back end that is fast and low overhead. Text files are one way of doing it but I am wondering if there is a better way for performance issues. I am still learning LDAP at this time so I do not have a full comprehension for the performance of it yet. Personally I think that the registry is the biggest problem with speed in Windows so that is why I think we need to start at that end of it. We have to keep in mind that Linux is used differently then Windows. It has ties to slow links to run software over as well as smaller hardware. I typically run programs from work on my home system that is just a 56K modem. So any of them programs need to work fast (relatively speaking) as they do now or no configuration idea is going to take off. I would rather spend the time configuring the system if it means getting usable performance out of it. Well, that's my 2 cents worth. Brian >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 2/8/00, 2:58:25 PM, Steve Schveighoffer <[EMAIL PROTECTED]> wrote regarding Configuration: > Sorry for the bogus return address, but I noticed some spam posted to > the mailing list, and I prefer not to be spammed myself. If you need to > send me personal email, follow the directions at the bottom. > Anyways, I am a veteran linux user and have used it since the 1.0.x > days. I originally started by using slackware, then moved on to > RedHat. I also have used some unixes, most prominently Solaris and > IRIX. However, out of all these systems, I absolutely hate the way you > must configure each piece of software differently. Before you delete > this email hear me out. The one configuration system that has the right > idea is Microsoft's registry. Now, I used to HATE the registry, it has > all kinds of cryptic info, no editable text files, and no comments as to > how the entries affect the program. However, as I began to learn how > the registry was laid out, more and more, I found myself browsing to the > correct location in the registry to configure something in a program > that I knew nothing about. Then it hit me -- Window's layout of the > registry is a defacto standard as far as windows applications are > concerned, and that is why using the registry became so easy. Most > global program info goes under > HKEY_LOCAL_MACHINE\Software\<VENDOR>\<PROGRAM> and most user specific > info goes under HKEY_LOCAL_MACHINE\Software\<VENDOR>\<PROGRAM>. > I also used a tool on RedHat called linuxconf. Using linuxconf got me > thinking too. It is a great tool, but it no doubt is unnecessarily > bloated because it needs to know how to parse and edit multiple types of > configuration files. Not only that, but it is DOG SLOW. When you think > about how every program's configuration file is put in a different place > with a different format, you can begin to understand why linuxconf is > such a slug. > My idea is simple. Take the organization and simplicity of the windows > registry, and linuxize it. Use a file format that is human-readable and > editable, use the linux filesystem to organize the "Keys" and the file > permissions to implement security. Then, make the internal file format > easily parsible by a program. Here are the advantages that I see we can > have: > 1. Organization -- it is easy to find the configuration for a program, > you just look under /etc/config/<Category>/<Program> (for example). No > more do you have to search on the internet to find out how to configure > each individual program, you need only figure out how the configuration > is laid out, then proceed to the correct file. > 2. Elimination of redundancy -- if you have multiple types of config > files, you have more than one instance of file-parsing code. There > could be one shared library that exposes the correct methods to > programmers to easily parse the files. > 3. Streamlined and Global linuxconf -- the tool that edits/reads the > current configuration does not have to contain all the redundant code > from part 2. This allows a newbie user or normal everyday user to > configure the system without having to edit configuration files. Since > the directory structure is similar in all cases, the configuration > program doesn't need to have special knowledge about which programs are > on the system, it can just say "Hey, here's a directory inside the > /etc/config, I will present the interface to configure it to the user". > This allows the functionality of the tool to be worked on instead of > having to add new parts to the tool when some new essential program > comes out that the tool needs to configure for a newbie. > 4. Improved security -- if most programs use this configuration system, > security problems are contained within one library. Fixing security > bugs in that library fixes the security problems for all programs. > Right now, if some developer decides to introduce his tool with HIS > implementation of a config file format, it is more prone to security > problems, and every program must be tested instead of the global > library. > Here is one disadvantage to this system: > 1. Time & Effort -- it will take time and effort to not only develop > this system, but to migrate targeted programs to this system (something > that I am more than happy to donate my time to). However, this does not > prevent newer programs from being developed that use the system. > I am not an expert on file parsing and security, so which file format is > used is something I will leave up to whoever is the expert. However, > from what I've been hearing about XML, it sounds like something in that > direction would be good. It needs to be extendable, and very parsible > by software, yet editable by a human. Something that a perl or shell > script can manipulate will also be preferable for automation and > installation. It might also be good to put a similar directory > structure in the user's home directory for settings that are > user-specific. > OK, so there's my idea, I have typed all I can think of, I would > appreciate some feedback, good or bad. Thanks for your time. > -Steve > -- > To send email to me, send it to: > nihil aht gis dot net. > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with subject of "unsubscribe". Trouble? Email [EMAIL PROTECTED]
