Configuration

[Steve Schveighoffer]

Sorry you got caught by my !spam address, if you just reply to the list
and not to me, that won't happen, or follow the directions at the bottom
of my email.


See my comments below

Brian Schramm wrote:
> 
> 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.

OK, that sounds like a good idea.  It would prevent the need to move all
file formats to a new file type, because you could just write a module
to parse that file type.  The only issue you must concern yourself with
then is a program or user that needs to hand edit the files then still
needs to learn the file format.  I understand the idea of abstracting
the configuration, but I absolutely hate not having the ability to
configure a system with good old vi.  If the LSB was to promote a
standard config file format or protocol, having pluggable modules would
ease the migration process, and allow for partial migration.
 
> 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.

I cannot speak from much experience, but a colleague of mine who is more
familiar with the inner workings of Windows tells me that it is faster
to read/write the registry than text files.

> 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.

However, remember that most programs in linux CURRENTLY use a text file
configuration.  Therefore, moving where the text file is stored, and
streamlining how it is parsed is not going to slow down the
configuration parsing of the program.  On the contrary, if one standard
library is used to do configuration, it has a better chance of being
worked on than joe shmoes handy dandy configuration parser, and no doubt
many developers will find ways to speed it up, giving you better
performance.

I am not sure what you mean about running programs from work.  Even if
you are running programs from a mounted network drive, the program
currently gets its configuration from somewhere.  If it gets it from the
mounted filesystem, it won't make a difference which directory you store
the file in.  Look at the programs you currently run, and see if they
use text files to configure themselves.  If you run the programs ON the
server that you are logged into, the 56K connection is of no concern for
configuration issues.  It will not slow down your program because the
program is running ON the server, not your home machine.

Could you please clarify what you meant by "running programs from work
at home"?

> 
> Well, that's my 2 cents worth.
> 
> Brian
> 

Thanks for the input!

-Steve

-- 
To send email to me, send it to:
nihil aht gis dot net.