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.
