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.
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 2/8/00, 2:58:25 PM, Steve Schveighoffer <!firstname.lastname@example.org> wrote
> 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
> 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
> must configure each piece of software differently. Before you delete
> this email hear me out. The one configuration system that has the
> idea is Microsoft's registry. Now, I used to HATE the registry, it
> all kinds of cryptic info, no editable text files, and no comments as
> 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
> 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
> configuration files. Not only that, but it is DOG SLOW. When you
> about how every program's configuration file is put in a different
> 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
> registry, and linuxize it. Use a file format that is human-readable
> editable, use the linux filesystem to organize the "Keys" and the file
> permissions to implement security. Then, make the internal file
> easily parsible by a program. Here are the advantages that I see we
> 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
> each individual program, you need only figure out how the
> 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.
> the directory structure is similar in all cases, the configuration
> program doesn't need to have special knowledge about which programs
> 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
> 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
> 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
> 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
> that I am more than happy to donate my time to). However, this does
> prevent newer programs from being developed that use the system.
> I am not an expert on file parsing and security, so which file format
> 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
> 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
> 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.
> To send email to me, send it to:
> nihil aht gis dot net.
> To UNSUBSCRIBE, email to email@example.com
> with subject of "unsubscribe". Trouble? Email