Yes, here's the linux registry topic again. This project looks interesting. Any comments?
This is truly a horrible idea!!! Think about "how well" it works in windows. Or think AIX.
Neal D. Becker wrote:
Yes, here's the linux registry topic again. This project looks interesting. Any comments?
John W. Linville wrote:
Harry Hoffman wrote:
This is truly a horrible idea!!! Think about "how well" it works in windows. Or think AIX.
I absolutely agree! Having anything like the Windows Registry for Linux is a wretched, wretched idea...
You mean something like, oh I don't know... GConf(2)?
*ducks for cover* (-:
-- Rex
On Tue, 2004-07-27 at 15:15 -0400, John W. Linville wrote:
Harry Hoffman wrote:
This is truly a horrible idea!!! Think about "how well" it works in windows. Or think AIX.
I absolutely agree! Having anything like the Windows Registry for Linux is a wretched, wretched idea...
Yeah why do people want to move to a single config database anyways? So you can have a single point of failure for an entire server and all services? Or so one poorly written app can corrupt it all? Ya know I agree with you guys here.
-sb
John
-- John W. Linville linville@redhat.com
On Wed, 2004-07-28 at 11:15 -0400, Stan Bubrouski wrote:
On Tue, 2004-07-27 at 15:15 -0400, John W. Linville wrote:
Harry Hoffman wrote:
This is truly a horrible idea!!! Think about "how well" it works in windows. Or think AIX.
I absolutely agree! Having anything like the Windows Registry for Linux is a wretched, wretched idea...
Yeah why do people want to move to a single config database anyways? So you can have a single point of failure for an entire server and all services? Or so one poorly written app can corrupt it all? Ya know I agree with you guys here.
It does NOT have to be one file.
A libconfig (or something) that exports a standard API that programs use to look up configuration values. It writes PLAIN TEXT configuration files to somewhere in /etc in a consistent format across all applications that use it.
Most things store config files in /etc right now, so in the _current_ situation, if your /etc/ takes a dive, you're hosed. I fail to see how a config situation as described in the above paragraph would be _worse_ than what exists now.
The point of a good converged config project (IMHO) would be a _consistent_ _file_ _format_ in plain-text files, NOT a binary-only single-file registry. People simply don't seem to understand that.
Dan
A libconfig (or something) that exports a standard API that programs use to look up configuration values. It writes PLAIN TEXT configuration files to somewhere in /etc in a consistent format across all applications that use it.
Most things store config files in /etc right now, so in the _current_ situation, if your /etc/ takes a dive, you're hosed. I fail to see how a config situation as described in the above paragraph would be _worse_ than what exists now.
The point of a good converged config project (IMHO) would be a _consistent_ _file_ _format_ in plain-text files, NOT a binary-only single-file registry. People simply don't seem to understand that.
Dan
Kind of makes me wonder once again why the kernel itself can't handle a simple flat file config system ? Maybe Redhat style VARIABLE=value pairs. Its pure, its simple, you can edit it as plain text - best of all if it exists as a common API without dependency then people would use it.
Even the simplest embedded systems need some configuration, so it would be difficult to argue its not a kernel task.....
Jon
On Wed, 2004-07-28 at 16:38 +0100, Jonathan Andrews wrote:
Kind of makes me wonder once again why the kernel itself can't handle a simple flat file config system ? Maybe Redhat style VARIABLE=value pairs. Its pure, its simple, you can edit it as plain text - best of all if it exists as a common API without dependency then people would use it.
That's not a kernel job, but a userspace job. The kernel should keep managing hardware resources.
--On Wednesday, July 28, 2004 4:38 PM +0100 Jonathan Andrews jon@jonshouse.co.uk wrote:
Kind of makes me wonder once again why the kernel itself can't handle a simple flat file config system ? Maybe Redhat style VARIABLE=value pairs. Its pure, its simple, you can edit it as plain text - best of all if it exists as a common API without dependency then people would use it.
Like programming languages, config languages should provide expressability for many problem domains, and that means hierarchy is desirable. Indirection would also be a good feature. As would inheritance.
[...]
Yeah why do people want to move to a single config database anyways? So you can have a single point of failure for an entire server and all services? Or so one poorly written app can corrupt it all? Ya know I agree with you guys here.
[...]
A libconfig (or something) that exports a standard API that programs use to look up configuration values. It writes PLAIN TEXT configuration files to somewhere in /etc in a consistent format across all applications that use it.
Most things store config files in /etc right now, so in the _current_ situation, if your /etc/ takes a dive, you're hosed. I fail to see how a config situation as described in the above paragraph would be _worse_ than what exists now.
The point of a good converged config project (IMHO) would be a _consistent_ _file_ _format_ in plain-text files, NOT a binary-only single-file registry. People simply don't seem to understand that.
And consistency should bring /less/ failures because the total amount of configuration reading code would be greatly reduced.
-- Mike
I hope everyone can agree that the etc situation is coming to a head. And that we would benefit from a "uniform configuration format" (UCF) to ease the development of new GUI based configuration tools and simplify and standardize the format of existing file formats. Currently you can't manually edit most of these files if you use a GUI editor because of its inability to parse these documents lucidly (and understandably so). I suggest the development and optional adoption of a service that writes and stores these configuration files and manages the etc in an automated and lucid fashion. The xml based schema will allow hand editing of the xml files at any time but will most likely require a manual reread of thechanges after hand editing (acceptable because of the advanced operation of hand editing). Such a system of management can and should provide a distribution and desktop environment independent method of managing ALL configuration information (system-wide (etc) and userlevel (~/)).
If there is sincere interest i will be happy to compose a first draft or scour the web for a jumping off point and adapt it to our specifications. I will slap up a wiki and we can collectively develop the standards over the next few weeks. I think that such a development will single handedly improve the ease of development and usability of linux on the desktop and in the data center. This isnt an overly complicated initiative and from what i can tell and its necessity and improvements will far outweigh the development effort.
Recap: I am proposing the development of a document that sets out a distribution and desktop indepentent standardized method of system-wide and user based configueration information storage including the location of the files and the format of their contents.
Best Wishes, Michael Favia Insites Incorporated
On Wed, 28 Jul 2004 11:23:36 -0500, Michael Favia garbage@insitesinc.com wrote:
Recap: I am proposing the development of a document that sets out a distribution and desktop indepentent standardized method of system-wide and user based configueration information storage including the location of the files and the format of their contents.
Did you even read the registy.sf.net website that started this thread? what you are proposing is.. duplication of the effort at that website. Do we really need yet another independant method created and discussed, but which major projects have no interest in actually using? If you see a technical problem with registry.sf.net's api then go talk to them about it and get you problem addressed.
The problem is not the existence of a potential independant standard to replace how configuration is stored on disk. The problem is getting the major indpendent projects ( not the people building the distribution who have to stick all this crap together) to agree to use the same configuration format. Get apache and sendmail/postfix and bind and mozilla and gnome and kde etc etc etc etc to commit to finding a common configuration format to save information into. Do that first. Don't go off and try to create yet another techincally great idea in a vacuum that no major project is invested and committed in trying to use.
Get projects upstream looking at registry.sf.net and playing with registy.sf.net as a common implementation. If through experimentatal implementation by upstream problems register.sf.net has technical issues that require rework of the api there, then so be it. Creating yet another scheme and attempt that tries to be technical perfect before its even looked at by the major projects is just a waste of your time.
-jef
On Wed, 2004-07-28 at 08:27, Dan Williams wrote:
On Wed, 2004-07-28 at 11:15 -0400, Stan Bubrouski wrote:
Yeah why do people want to move to a single config database anyways? So you can have a single point of failure for an entire server and all services? Or so one poorly written app can corrupt it all? Ya know I agree with you guys here.
The point of a good converged config project (IMHO) would be a _consistent_ _file_ _format_ in plain-text files, NOT a binary-only single-file registry. People simply don't seem to understand that.
Well, the typical Linux groupie has a pretty fixed and simple schema to evaluate everything:
- Looks Like Linux = Good (TM) - Looks Like Windows = Bad (TM)
The Windows registry has some shortcomings, indeed, but all of them are stemming from the fact that the WinReg's storage backend is a SPoF (single point of failure). The abstract idea of a unified config mechanism is good, and you pretty much exhausted the arguments for that, it's just that the concrete implementation of it has to be designed in such a way as to minimize (if not snuff out altogether) the SPoF.
For as long as i've been playing with Linux i've been dreaming of a way to get out of the "Every App Has It's Own Fancy Schmancy Incompatible Config File Format" hell. I envied Windows for its registry while at the same time being aware of the problems of a registry implemented badly. And it looks like the Linux Registry goes a bit even further than WinReg, if i understand it correctly.
On Jul 28, 2004, Dan Williams dcbw@redhat.com wrote:
It writes PLAIN TEXT configuration files to somewhere in /etc in a consistent format across all applications that use it.
Consistent format as in format that differs from most standard formats chosen by applications, while being identical to a few of them? Or consistent as in different from them all? :-)
Not that I'm advocating it (I'm don't care one way or the other), but most Linux people dislike the windows registry for reasons this project would fix:
- All key-value pairs are stored in clear-text files. (Windows uses binary files(?)) (Next question, how about nested values...
- It is designed to be easy to administrate with regular command line tools like cat, vi, cp, ls, ln. Its storage is 100% open. (this is also a common argument against Windows Registry by anti-registry folk)
Anybody can abuse a flat text file config system too, just as much as the Windows Registry becomes a horrible mess.
Dan
On Tue, 2004-07-27 at 15:08 -0400, Harry Hoffman wrote:
This is truly a horrible idea!!! Think about "how well" it works in windows. Or think AIX.
Neal D. Becker wrote:
Yes, here's the linux registry topic again. This project looks interesting. Any comments?
Dan, I wish more people would take the time to read the material before blasting it based on assumptions. OTOH, it might be a fatal mistake to have the project called 'Linux Registry'.
I was sceptical when I started reading, but got converted. I actually like the idea.
On Tuesday 27 July 2004 12:18, Dan Williams wrote:
Not that I'm advocating it (I'm don't care one way or the other), but most Linux people dislike the windows registry for reasons this project would fix:
- All key-value pairs are stored in clear-text files. (Windows uses
binary files(?)) (Next question, how about nested values...
- It is designed to be easy to administrate with regular command line
tools like cat, vi, cp, ls, ln. Its storage is 100% open. (this is also a common argument against Windows Registry by anti-registry folk)
Anybody can abuse a flat text file config system too, just as much as the Windows Registry becomes a horrible mess.
Hi,
I was actually defending the project :) I _do_ personally think that Linux needs some more consistent configuration. It may be that each program gets its own flat text file in a specific location (most likely under /etc) but uses a library with a consistent API to write to that file. Therefore, an administrator would be able to change the file just fine, but normal *nix permissions would still apply and nobody would be able to "walk all over everybody's keys".
At least most config files are now under /etc on Linux, but each file having a completely different format is somewhat off.
Dan
On Tue, 27 Jul 2004, Remco Treffkorn wrote:
Dan, I wish more people would take the time to read the material before blasting it based on assumptions. OTOH, it might be a fatal mistake to have the project called 'Linux Registry'.
I was sceptical when I started reading, but got converted. I actually like the idea.
On Tuesday 27 July 2004 12:18, Dan Williams wrote:
Not that I'm advocating it (I'm don't care one way or the other), but most Linux people dislike the windows registry for reasons this project would fix:
- All key-value pairs are stored in clear-text files. (Windows uses
binary files(?)) (Next question, how about nested values...
- It is designed to be easy to administrate with regular command line
tools like cat, vi, cp, ls, ln. Its storage is 100% open. (this is also a common argument against Windows Registry by anti-registry folk)
Anybody can abuse a flat text file config system too, just as much as the Windows Registry becomes a horrible mess.
-- Remco Treffkorn (RT445) HAM DC2XT remco@rvt.com (831) 685-1201
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
On Tue, 27 Jul 2004 15:18:31 -0400, Dan Williams dcbw@redhat.com wrote:
Not that I'm advocating it (I'm don't care one way or the other), but
Let's say someone was to advocate its usage, is it really all that useful to advocate it at the distribution level? Reading the webpage there is lots and lots of talk about sysadmins having problems adapting across distributions or across configurations of different projects. Having the change in Fedora instead of upstream doesn't seem to make a lot of sense as a solution to the problems being addressed.
Looking at all the examples on the webpage, id saying making those changes at the distribution level is dangerous and adds tons of maintainership burden. This needs to be advocated upstream if this is going to be useful. At most, the this api can be contrasted with the current sysconfig approach for the distribution specific initscript stuff, but there is no way this is an appropriate approach for general usage (even if its technically better) unless upstream maintainers for projects agree to use it. Like the webpage says, the trick isnt so much the technology but that people have to agree to use this. If upstream projects don't agree to use it, then then implementing it at the distribution level is going to just add that much more confusion.
-jef"the phrase 'cat herding' comes to mind when i think about trying to get people to agree to use any configuration api"spaleta
On Tue, 2004-07-27 at 16:56 -0400, Jeff Spaleta wrote:
Looking at all the examples on the webpage, id saying making those changes at the distribution level is dangerous and adds tons of maintainership burden. This needs to be advocated upstream if this is going to be useful. At most, the this api can be contrasted with the current sysconfig approach for the distribution specific initscript stuff, but there is no way this is an appropriate approach for general usage (even if its technically better) unless upstream maintainers for projects agree to use it. Like the webpage says, the trick isnt so much the technology but that people have to agree to use this. If upstream projects don't agree to use it, then then implementing it at the distribution level is going to just add that much more confusion.
This is exactly right. No distribution is going to patch every application to use this 'registry' instead of it's regular config file format. If the changes are made upstream, the distros will inherit this and have to deal with it. I think the there are at least three big hurdles that this project faces:
1) Registry in the name - too many negative connotations 2) Linux in the name - it isn't Linux specific. *BSD folks wouldn't even think it's remotely relevant to them even though the project admits that it isn't a Linux specific thing. 3) Upstream projects would need to migrate to it - I really can't say that I see that happening en masse.
Nice idea, definitely better than the Windows implementation of the registry (but then, what isn't?). I would be interested to know what kind of bog down it would face on a system with a bunch of applications and the like and to start having either really large text files to parse through for values or a whole bunch of little files that start showing certain filesystems dislike of such situations....
Someone will eventually have to answer the question of why this is better than using LDAP, PAM, and/or kerberos. Those are all open standards and well known by a large population of *nix SAs.
I would go further and say not only will you not see upstream projects migrating en masse, but in many cases, you will not see them migrating at all.
Steve Brenneis http://myorb.sourceforge.net
On Tue, 2004-07-27 at 18:38, David T Hollis wrote:
On Tue, 2004-07-27 at 16:56 -0400, Jeff Spaleta wrote:
Looking at all the examples on the webpage, id saying making those changes at the distribution level is dangerous and adds tons of maintainership burden. This needs to be advocated upstream if this is going to be useful. At most, the this api can be contrasted with the current sysconfig approach for the distribution specific initscript stuff, but there is no way this is an appropriate approach for general usage (even if its technically better) unless upstream maintainers for projects agree to use it. Like the webpage says, the trick isnt so much the technology but that people have to agree to use this. If upstream projects don't agree to use it, then then implementing it at the distribution level is going to just add that much more confusion.
This is exactly right. No distribution is going to patch every application to use this 'registry' instead of it's regular config file format. If the changes are made upstream, the distros will inherit this and have to deal with it. I think the there are at least three big hurdles that this project faces:
- Registry in the name - too many negative connotations
- Linux in the name - it isn't Linux specific. *BSD folks wouldn't
even think it's remotely relevant to them even though the project admits that it isn't a Linux specific thing. 3) Upstream projects would need to migrate to it - I really can't say that I see that happening en masse.
Nice idea, definitely better than the Windows implementation of the registry (but then, what isn't?). I would be interested to know what kind of bog down it would face on a system with a bunch of applications and the like and to start having either really large text files to parse through for values or a whole bunch of little files that start showing certain filesystems dislike of such situations....
-- David T Hollis dhollis@davehollis.com
--On Tuesday, July 27, 2004 7:24 PM -0400 Steve Brenneis sbrenneis@surry.net wrote:
Someone will eventually have to answer the question of why this is better than using LDAP, PAM, and/or kerberos. Those are all open standards and well known by a large population of *nix SAs.
Another standard to consider is ACAP, currently supported by Eudora and Mulberry (both IMAP email clients).
Mulberry also supports something called IMSP:
On Tue, Jul 27, 2004 at 06:59:03PM -0700, Kenneth Porter wrote:
Another standard to consider is ACAP, currently supported by Eudora and Mulberry (both IMAP email clients).
ACAP is extremely hard to implement, that makes it a poor choice for most system functionality because complex means fragile and buggy. It also really only solves the "where" part of the question not the "what format" part.
Now personally I'd like to see apps develop the ability to also read an XML config format for their config files but thats an upstream problem
On Jul 28, 2004, Alan Cox alan@redhat.com wrote:
Now personally I'd like to see apps develop the ability to also read an XML config format for their config files but thats an upstream problem
Having e.g. /etc/sysconfig files changed to xml formats and having to parse that from init.d shell scripts certainly isn't going to make the system boot faster :-/
--On Monday, August 02, 2004 2:46 AM -0300 Alexandre Oliva aoliva@redhat.com wrote:
Having e.g. /etc/sysconfig files changed to xml formats and having to parse that from init.d shell scripts certainly isn't going to make the system boot faster :-/
For the kinds of things stored in sysconfig, would XML be that much more complex?
On Aug 4, 2004, Kenneth Porter shiva@sewingwitch.com wrote:
--On Monday, August 02, 2004 2:46 AM -0300 Alexandre Oliva aoliva@redhat.com wrote:
Having e.g. /etc/sysconfig files changed to xml formats and having to parse that from init.d shell scripts certainly isn't going to make the system boot faster :-/
For the kinds of things stored in sysconfig, would XML be that much more complex?
How do you obtain the equivalent of `. /etc/sysconfig/whatever' from whatever.xml?
On Thu, 2004-08-05 at 09:32, Alexandre Oliva wrote:
On Aug 4, 2004, Kenneth Porter shiva@sewingwitch.com wrote:
--On Monday, August 02, 2004 2:46 AM -0300 Alexandre Oliva aoliva@redhat.com wrote:
Having e.g. /etc/sysconfig files changed to xml formats and having to parse that from init.d shell scripts certainly isn't going to make the system boot faster :-/
For the kinds of things stored in sysconfig, would XML be that much more complex?
How do you obtain the equivalent of `. /etc/sysconfig/whatever' from whatever.xml?
It depends on what you are trying to do.
If you want to include something, it can be as simple as:
<include> <file> /etc/sysconfig/whatever </file> <file> /etc/sysconfig/somethingelse </file> </include>
Then your XML loader looks for these elements to load additional configuration.
Or, if you want to source environment, you could do something like:
<environment> <file mime-type='text/plain'> /etc/sysconfig/whatever </file> <file mime-type='text/xml'> /etc/sysconfig/morestuff.xml </file> </environment>
If your included environment is in XML, you could even do things like:
<environment> <file mime-type='text/xml'> <name> /etc/sysconfig/morestuff.xml </name> <xpath> /environment/local[@user='someone'] </xpath> </file> </environment>
This would allow extraction of local, user-specific environments.
The possibilities are endless. As long as one doesn't over-use structure, XML is no more difficult to parse than plain text. However, it is far safer, far more likely to actually model the configuration data structures, and has a quicker learning curve for humans looking into the configuration for the first time.
--On Saturday, August 07, 2004 6:58 AM -0400 Steve Brenneis sbrenneis@surry.net wrote:
Or, if you want to source environment, you could do something like:
<environment> <file mime-type='text/plain'> /etc/sysconfig/whatever </file> <file mime-type='text/xml'> /etc/sysconfig/morestuff.xml </file> </environment>
I think his question was what to put in a shell script that would be able to source an XML file into the shell's variables and environment. Currently most initscript sysconfig files are just bash scriptlets that assign shell variables and are easily parsed with the bash dot (source) operator.
On Tue, 2004-07-27 at 19:24 -0400, Steve Brenneis wrote:
Someone will eventually have to answer the question of why this is better than using LDAP, PAM, and/or kerberos. Those are all open standards and well known by a large population of *nix SAs.
I still don't see the point of either using Linux Registry or LDAP over plain-text configuration files. LDAP is a network service, and thus, has its inherent problems: keeping local configuration on the network creates problems like poor performance, SPoF, DoS, etc.
Windows uses Active Directory (LDAP + Kerberos, mainly) for authentication and to publish Policies and configuration data on the network for domain members (computers and users), which are then integrated locally and periodically into the Registry of each domain member (that's the Applying Policies steps that is performed by WinLogon during boot). Domain members DO NOT take configuration data directly from the network, but from the local Registry. Trying to gather configuration data directly from the network (i.e. LDAP) is a serious error, IMHO.
Without detouring off-topic too far, in certain situations, LDAP configuration allows for consistency that may be critical. For instance, in some parallel and clustered systems that share resources like file systems, memory, and even process space, identical configuration of users, groups, and other details is essential.
So, for instance, if you are the SA running a 30 node cluster, and you have to deal with a local registry, you now have to duplicate everything you do across 30 nodes. Whereas, with LDAP configuration, you perform the action once. Fewer chances to get it wrong, fewer chances to do injury to critical enterprise components. Yes, this gives you a single point of failure, but if this becomes difficult, then you simply run slurpd on a backup system and in the event of a failure, you need only change one config file on all your systems and you are back up and running again.
That's just one example. I'm sure there are more.
On Wed, 2004-07-28 at 04:06, Felipe Alfaro Solana wrote:
On Tue, 2004-07-27 at 19:24 -0400, Steve Brenneis wrote:
Someone will eventually have to answer the question of why this is better than using LDAP, PAM, and/or kerberos. Those are all open standards and well known by a large population of *nix SAs.
I still don't see the point of either using Linux Registry or LDAP over plain-text configuration files. LDAP is a network service, and thus, has its inherent problems: keeping local configuration on the network creates problems like poor performance, SPoF, DoS, etc.
Windows uses Active Directory (LDAP + Kerberos, mainly) for authentication and to publish Policies and configuration data on the network for domain members (computers and users), which are then integrated locally and periodically into the Registry of each domain member (that's the Applying Policies steps that is performed by WinLogon during boot). Domain members DO NOT take configuration data directly from the network, but from the local Registry. Trying to gather configuration data directly from the network (i.e. LDAP) is a serious error, IMHO.
On Wed, 2004-07-28 at 10:47, Steve Brenneis wrote:
Without detouring off-topic too far, in certain situations, LDAP configuration allows for consistency that may be critical. For instance, in some parallel and clustered systems that share resources like file systems, memory, and even process space, identical configuration of users, groups, and other details is essential.
...
That's just one example. I'm sure there are more.
I agree. I think that LDAP coudl be used more on clusters.
I think though that people see LDAP as a 'NIS replacement' for the users and groups functions, and go for things like LCFG and cfengine for the 'system' type settings. Just my two penny worth - as I think LDAP could have uses there too.
Once upon a time, John Hearns john.hearns@clustervision.com said:
I think though that people see LDAP as a 'NIS replacement' for the users and groups functions, and go for things like LCFG and cfengine for the 'system' type settings. Just my two penny worth - as I think LDAP could have uses there too.
One thing about OpenLDAP is that you have to shut it down to add new schema. That means if you install a new program that wants to add to the schema for its config, the OpenLDAP server has to be stopped and restarted, and there's always a chance (especially when changing config) that it won't restart. Also, the security controls are somewhat arcane (and also probably need to be "touched" when modifying the schema for something new).
On Wed, 2004-07-28 at 11:08 +0100, John Hearns wrote:
On Wed, 2004-07-28 at 10:47, Steve Brenneis wrote:
Without detouring off-topic too far, in certain situations, LDAP configuration allows for consistency that may be critical. For instance, in some parallel and clustered systems that share resources like file systems, memory, and even process space, identical configuration of users, groups, and other details is essential.
...
That's just one example. I'm sure there are more.
I agree. I think that LDAP coudl be used more on clusters.
I think though that people see LDAP as a 'NIS replacement' for the users and groups functions, and go for things like LCFG and cfengine for the 'system' type settings. Just my two penny worth - as I think LDAP could have uses there too.
Yeah, of couse... LDAP can keep authentication/identification data accessible from the network, but not configuration data. Keeping critical configuration on the network creates unnecessary points of failures. Please, let's try to keep configuration data centrally.
If it cant be edited by a text editor its a bad idea.
Why doesn't the Linux kernel have an API for maintaining VARIABLE=value type text files built in?
I wrote a little utility for doing the job called "readwriteconfig".
If configuration files are structured properly they have all the benefit of a registry without the unmaintainable mess problem.
Jon
On Wed, Jul 28, 2004 at 03:38:50PM +0100, Jonathan Andrews wrote:
Why doesn't the Linux kernel have an API for maintaining VARIABLE=value type text files built in?
Ow. Why would you want that in the kernel?
On Wed, 2004-07-28 at 16:38, Matthew Miller wrote:
On Wed, Jul 28, 2004 at 03:38:50PM +0100, Jonathan Andrews wrote:
Why doesn't the Linux kernel have an API for maintaining VARIABLE=value type text files built in?
Ow. Why would you want that in the kernel?
1) Everything more than "Hello world" needs to store some configuration, so doesn't that make it a requirement of most applications hence a lot of processes within the application.
2) By putting a simple quick and understandable system in the kernel its more likely to be adopted. 3) Present in the kernel = No dependency on external libs, making it more likely to be adopted.
4) Kernel = common API - if people would only need another API if the configuration need was more complex than the base line, and mostly it is not.
This will give rise to common standards, if the kernel is always only just enough then you end up with everyone having to code a slightly different variant of the same code to achieve the same result, as happens with configuration now.
5) Why not show some leadership instead of just cloning Unix/Posix - "As little as possible" need not be that same as "Not enough to be complete"
Jon
[further discussion here should be moved off of the fedora-devel list -- this is basically just noise to the poor fedora developers. So I've set reply-to to me.]
On Wed, Jul 28, 2004 at 04:52:17PM +0100, Jonathan Andrews wrote:
- Everything more than "Hello world" needs to store some configuration,
so doesn't that make it a requirement of most applications hence a lot of processes within the application.
That's not necessarily true.
- By putting a simple quick and understandable system in the kernel its
more likely to be adopted.
Heh. Go propose this on the linux-kernel mailing list and see how quickly it gets anywhere, let alone adopted. This is a totally user-space task, and would just add bloat to the kernel (and attendant additional security concerns).
- Present in the kernel = No dependency on external libs, making it
more likely to be adopted.
Well, the point aside above, that's not necessarily true either. You could put it in libc. (But still shouldn't.)
- Kernel = common API - if people would only need another API if the
configuration need was more complex than the base line, and mostly it is not.
There's quite a lot more to the common Unix API than kernel syscalls already.
- Why not show some leadership instead of just cloning Unix/Posix - "As
little as possible" need not be that same as "Not enough to be complete"
This isn't leadership -- it'd be a step backward. The kernel should stick to the minimal set of core functionality needed for a *kernel*. In fact, there's talk of moving things like the IDE drivers into user space. Putting a config file finding and parsing routine into the kernel would be, frankly, horrid.
On Wed, 2004-07-28 at 17:02, Matthew Miller wrote:
[further discussion here should be moved off of the fedora-devel list -- this is basically just noise to the poor fedora developers. So I've set reply-to to me.]
On Wed, Jul 28, 2004 at 04:52:17PM +0100, Jonathan Andrews wrote:
- Everything more than "Hello world" needs to store some configuration,
so doesn't that make it a requirement of most applications hence a lot of processes within the application.
That's not necessarily true.
- By putting a simple quick and understandable system in the kernel its
more likely to be adopted.
Heh. Go propose this on the linux-kernel mailing list and see how quickly it gets anywhere, let alone adopted. This is a totally user-space task, and would just add bloat to the kernel (and attendant additional security concerns).
- Present in the kernel = No dependency on external libs, making it
more likely to be adopted.
Well, the point aside above, that's not necessarily true either. You could put it in libc. (But still shouldn't.)
- Kernel = common API - if people would only need another API if the
configuration need was more complex than the base line, and mostly it is not.
There's quite a lot more to the common Unix API than kernel syscalls already.
- Why not show some leadership instead of just cloning Unix/Posix - "As
little as possible" need not be that same as "Not enough to be complete"
This isn't leadership -- it'd be a step backward. The kernel should stick to the minimal set of core functionality needed for a *kernel*. In fact, there's talk of moving things like the IDE drivers into user space. Putting a config file finding and parsing routine into the kernel would be, frankly, horrid.
Minimal for who ?? Configuration state is just as much a need for processes as RAM or files. Even the flash based set to box will get turned on and off !
I have seen variants on the same 200 lines of code for 10 years, even windows had an API for ".ini" files from windows 3.11, yet Unix/Linux still has no common configuration standard.... Now we have some people pushing for XML and other horrors - if the O/S had tackled the problem head on then the differences between distributions would be less and the portability of configuration would be greater. Unix people seem to agree small files, plain text - yet they have no common API ?? Doesn't this just contribute to the mess !
Anyone who has maintained windows doesn't want a registry, or any large database, but an API to grep from files and to replace text would solve most problems for flat file configuration.
Ok, I bow to one who knows more than me - so its a user space problem, I still think a common (thats to all distributions) API for configuration should exist, where do you think it should live - Is it not a core requirement for applications ? If so it should be a common component of all Linux ? Maybe it should be in libc ? It would make grep simpler to write :-)
Jon
On Wed, Jul 28, 2004 at 05:28:11PM +0100, Jonathan Andrews wrote:
Minimal for who ?? Configuration state is just as much a need for processes as RAM or files. Even the flash based set to box will get turned on and off !
Minimal for "_needs_ to be in the kernel". This clearly doesn't need that level of privilege, and there would be no technical benefit, so it has no business being there.
Ok, I bow to one who knows more than me - so its a user space problem, I still think a common (thats to all distributions) API for configuration should exist, where do you think it should live - Is it not a core requirement for applications ? If so it should be a common component of all Linux ? Maybe it should be in libc ? It would make grep simpler to write :-)
It might be okay as part of libc. But honestly, I think that would make such a library _less_ widely used. Programs should be portable between flavors of *nix, and if the Linux version has this weird non-portable extension, it won't do much. Better to make it a separate, small library. And, there's several such libraries in existence already (look on Freshmeat). I think what you should do is pick the best one, and work to get that in the Linux Standard Base.
On Wed, 2004-07-28 at 17:28 +0100, Jonathan Andrews wrote:
I have seen variants on the same 200 lines of code for 10 years, even windows had an API for ".ini" files from windows 3.11, yet Unix/Linux still has no common configuration standard.... Now we have some people pushing for XML and other horrors - if the O/S had tackled the problem head on then the differences between distributions would be less and the portability of configuration would be greater. Unix people seem to agree small files, plain text - yet they have no common API ?? Doesn't this just contribute to the mess !
No, as what could seem best suited for one couldn't be flexible/scalable for another. I think that trying to find a single configuration scheme (one-size-fits-all) is a bad idea. Just imagine storing thousands Snort rules on a Windows-like registry.
The KEY=value methapor is not well suited for every kind of application.
On mer, 2004-07-28 at 17:28 +0100, Jonathan Andrews wrote:
Anyone who has maintained windows doesn't want a registry, or any large database, but an API to grep from files and to replace text would solve most problems for flat file configuration.
Which is why XML is way better than flat text files BTW
On Wed, 2004-07-28 at 16:52 +0100, Jonathan Andrews wrote:
Ow. Why would you want that in the kernel?
- Everything more than "Hello world" needs to store some configuration,
so doesn't that make it a requirement of most applications hence a lot of processes within the application.
That's not a valid reason to put it into the kernel.
- By putting a simple quick and understandable system in the kernel its
more likely to be adopted.
False.. You could put it up onto glibc as well.
- Present in the kernel = No dependency on external libs, making it
more likely to be adopted.
That's not a valid reason. Enlarging the kernel with userspace features is kind of useless.
- Kernel = common API - if people would only need another API if the
configuration need was more complex than the base line, and mostly it is not.
Again, false. There are good APIs out there which are not implemented in kernelspace, like X11, glibc, gtk, etc.
- Why not show some leadership instead of just cloning Unix/Posix - "As
little as possible" need not be that same as "Not enough to be complete"
Because leadership doesn't allow one to start screwing a working system.
On Wed, 2004-07-28 at 15:38 +0100, Jonathan Andrews wrote:
If it cant be edited by a text editor its a bad idea.
No, it's not... If something is damaged, broken or corrupted, it can be easily fixed by using a simple line or text editor. You can even boot from a bootable recue CD and fix the problem. Can you do that with Windoze propietary, binary, monolithic registry? No.
On Wed, 2004-07-28 at 17:33, Felipe Alfaro Solana wrote:
On Wed, 2004-07-28 at 15:38 +0100, Jonathan Andrews wrote:
If it cant be edited by a text editor its a bad idea.
No, it's not... If something is damaged, broken or corrupted, it can be easily fixed by using a simple line or text editor. You can even boot from a bootable recue CD and fix the problem. Can you do that with Windoze propietary, binary, monolithic registry? No.
Errrrr .... so like I said
"If it CANT be edited by a text editor its a BAD idea" ???
You have just argued that you agree with that I said ? My original post was poor English, I apologise - but I think you have miss understood. Im pushing for plain text - but with an API for manipulating text. My key point is that the API should be common to all Linux, not left for people to write the same code over and over again ....
1) reading VARIABLE=value pairs and 2) writing VARIABLE=value pairs.
So the plain text file with this
DEVICE=eth0 BOOTPROTO=none ONBOOT=yes IPADDR=10.10.10.5 NETMASK=255.255.255.0 USERCTL=no PEERDNS=no GATEWAY=10.10.10.1 TYPE=Ethernet
could be altered with a function like this
result=write_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT","no");
and
result=read_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT",&mystring);
See ... simple for programmer - and all plain text.
Jon
On Wed, 2004-07-28 at 17:48 +0100, Jonathan Andrews wrote:
You have just argued that you agree with that I said ? My original post was poor English, I apologise - but I think you have miss understood. Im pushing for plain text - but with an API for manipulating text. My key point is that the API should be common to all Linux, not left for people to write the same code over and over again ....
- reading VARIABLE=value pairs and
- writing VARIABLE=value pairs.
There are several copies of what is basically a small library to do this scattered across various Red Hat developed packages. Take a look at shvar.c in such packages as initscripts and authconfig (there are more copies I think, but those are the ones that I quickly locate with a find on my cvs checkouts :-)
Jeremy
On Wed, 2004-07-28 at 17:48 +0100, Jonathan Andrews wrote:
On Wed, 2004-07-28 at 17:33, Felipe Alfaro Solana wrote:
On Wed, 2004-07-28 at 15:38 +0100, Jonathan Andrews wrote:
If it cant be edited by a text editor its a bad idea.
No, it's not... If something is damaged, broken or corrupted, it can be easily fixed by using a simple line or text editor. You can even boot from a bootable recue CD and fix the problem. Can you do that with Windoze propietary, binary, monolithic registry? No.
Errrrr .... so like I said "If it CANT be edited by a text editor its a BAD idea" ???
Yep! I misread your sentence. Sorry.
- reading VARIABLE=value pairs and
- writing VARIABLE=value pairs.
So the plain text file with this
DEVICE=eth0 BOOTPROTO=none ONBOOT=yes IPADDR=10.10.10.5 NETMASK=255.255.255.0 USERCTL=no PEERDNS=no GATEWAY=10.10.10.1 TYPE=Ethernet
could be altered with a function like this
result=write_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT","no");
and
result=read_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT",&mystring);
Yeah! For really simple configuration information, this could be useful. Now try expressing thousands of Snort rules with that scheme, and your head will start aching.
result=write_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT","no");
and
result=read_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT",&mystring);
Yeah! For really simple configuration information, this could be useful. Now try expressing thousands of Snort rules with that scheme, and your head will start aching.
So it should be available for the 80% of tasks that its good enough, the 20% can code their own configuration. If a simple, clear API for text is available (and portable across distribution) then people will use it. If its complex then it probably isn't general purpose anyway !
On Wed, 2004-07-28 at 17:48 +0100, Jonathan Andrews wrote:
On Wed, 2004-07-28 at 17:33, Felipe Alfaro Solana wrote:
On Wed, 2004-07-28 at 15:38 +0100, Jonathan Andrews wrote:
If it cant be edited by a text editor its a bad idea.
No, it's not... If something is damaged, broken or corrupted, it can be easily fixed by using a simple line or text editor. You can even boot from a bootable recue CD and fix the problem. Can you do that with Windoze propietary, binary, monolithic registry? No.
Errrrr .... so like I said
"If it CANT be edited by a text editor its a BAD idea" ???
You have just argued that you agree with that I said ? My original post was poor English, I apologise - but I think you have miss understood. Im pushing for plain text - but with an API for manipulating text. My key point is that the API should be common to all Linux, not left for people to write the same code over and over again ....
- reading VARIABLE=value pairs and
- writing VARIABLE=value pairs.
So the plain text file with this
DEVICE=eth0 BOOTPROTO=none ONBOOT=yes IPADDR=10.10.10.5 NETMASK=255.255.255.0 USERCTL=no PEERDNS=no GATEWAY=10.10.10.1 TYPE=Ethernet
could be altered with a function like this
result=write_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT","no");
and
result=read_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT",&mystring);
See ... simple for programmer - and all plain text.
This is probably a perverse viewpoint (I'm an XML junkie), but I don't think this is simple. Some awkward questions: - What encoding are the names? the values? - What if a name or a value needs to contain an equals sign, a carriage return, or a line feed? (What about DOS vs UNIX linefeeds for that matter?) - How long can a name be? - How long can a value be? - Is case significant? - What happens if a text file contains multiple lines with the same VARIABLE name? - What happens if a text file contains multiple lines with variables that map to the same unicode string after canonicalisation, but which are different before canonicalisation? - Do you canonicalise variable names when testing for equality? - Does ordering matter? How is this expressed in the API? - What whitespace (if any) are you allowed in the file? Can this be represented/manipulated within the API? - Can the text file contain comments? Can it contain blank lines? Can these be represented/manipulated within the API?
Jon
--On Wednesday, July 28, 2004 9:32 PM -0400 David Malcolm dmalcolm@redhat.com wrote:
- Does ordering matter? How is this expressed in the API?
Yep, an example would be iptables rules. It would be nice to have a representation that handles ordered hierarchical data with indirection (eg. for jumps to subchains). Maybe something like a dump of a Perl data structure. Or will XML do all that?
On mer, 2004-08-04 at 13:47 -0700, Kenneth Porter wrote:
--On Wednesday, July 28, 2004 9:32 PM -0400 David Malcolm dmalcolm@redhat.com wrote:
- Does ordering matter? How is this expressed in the API?
Yep, an example would be iptables rules. It would be nice to have a representation that handles ordered hierarchical data with indirection (eg. for jumps to subchains). Maybe something like a dump of a Perl data structure. Or will XML do all that?
XML can do ordered hierarchical data with indirection easily.
Cheers,
On Wed, 2004-07-28 at 05:47 -0400, Steve Brenneis wrote:
Without detouring off-topic too far, in certain situations, LDAP configuration allows for consistency that may be critical. For instance, in some parallel and clustered systems that share resources like file systems, memory, and even process space, identical configuration of users, groups, and other details is essential.
So, for instance, if you are the SA running a 30 node cluster, and you have to deal with a local registry, you now have to duplicate everything you do across 30 nodes. Whereas, with LDAP configuration, you perform the action once. Fewer chances to get it wrong, fewer chances to do injury to critical enterprise components. Yes, this gives you a single point of failure, but if this becomes difficult, then you simply run slurpd on a backup system and in the event of a failure, you need only change one config file on all your systems and you are back up and running again.
That's just one example. I'm sure there are more.
While I agree LDAP has its place in centrally administered scenarios, I don't think this is valid for FC. Fedora is aimed at the desktop, not at the data center.
Felipe Alfaro Solana wrote:
On Tue, 2004-07-27 at 19:24 -0400, Steve Brenneis wrote:
Someone will eventually have to answer the question of why this is better than using LDAP, PAM, and/or kerberos. Those are all open standards and well known by a large population of *nix SAs.
I still don't see the point of either using Linux Registry or LDAP over plain-text configuration files.
Per SF L. Registry:
All key-value pairs are stored in clear-text files
LDAP is a network service, and thus, has its inherent problems: keeping local configuration on the network creates problems like poor performance, SPoF, DoS, etc.
Windows uses Active Directory (LDAP + Kerberos, mainly) for authentication and to publish Policies and configuration data on the network for domain members (computers and users), which are then integrated locally and periodically into the Registry of each domain member (that's the Applying Policies steps that is performed by WinLogon during boot). Domain members DO NOT take configuration data directly from the network, but from the local Registry. Trying to gather configuration data directly from the network (i.e. LDAP) is a serious error, IMHO.
Steve Brenneis wrote:
Someone will eventually have to answer the question of why this is better than using LDAP, PAM, and/or kerberos.
Because unlike those examples the L. Registry (per the sf web page):
""" IS designed to be secure and lightweight, to let even early boot-stage programs like */sbin/init* to use it, instead of /etc/inittab file. Is NOT an OS service that can become unavailable and make system unusable. It is just a library to access files according to a namespace. Is NOT an alternative to network information systems like LDAP or NIS. These are still required for networked environments. """
Mark
Yes, Flat text files can be munged pretty bad but the point is that they can only munge themselves. In a registry there is the possibility of editing fsck$#!ing all of the entries (yeah, backups... I know). Still not a good idea :-)
Cheers, Harry
Dan Williams wrote:
Not that I'm advocating it (I'm don't care one way or the other), but most Linux people dislike the windows registry for reasons this project would fix:
- All key-value pairs are stored in clear-text files. (Windows uses
binary files(?)) (Next question, how about nested values...
- It is designed to be easy to administrate with regular command line
tools like cat, vi, cp, ls, ln. Its storage is 100% open. (this is also a common argument against Windows Registry by anti-registry folk)
Anybody can abuse a flat text file config system too, just as much as the Windows Registry becomes a horrible mess.
Dan
On Tue, 2004-07-27 at 15:08 -0400, Harry Hoffman wrote:
This is truly a horrible idea!!! Think about "how well" it works in windows. Or think AIX.
Neal D. Becker wrote:
Yes, here's the linux registry topic again. This project looks interesting. Any comments?
You did not read the site, did you ?-) I really urge people to look at it. "Registry" is a poor choice for a name. Too many negative prejudices.
It would make my life a lot nicer! Maybe we should ask upstream to have a look.
On Tuesday 27 July 2004 14:30, Harry Hoffman wrote:
Yes, Flat text files can be munged pretty bad but the point is that they can only munge themselves. In a registry there is the possibility of editing fsck$#!ing all of the entries (yeah, backups... I know). Still not a good idea :-)
Remco, Ok, you caught me... I didn't fully read it. Now that I have, you're right I am being a bit harsh :-)
And yes, "registry" does indeed bring forth certain prejudices. I recon this is somewhat akin to reaching a Common Log Format, a good aim but something which needs a good bit of debate and agreement.
Cheers, Harry
Remco Treffkorn wrote:
You did not read the site, did you ?-) I really urge people to look at it. "Registry" is a poor choice for a name. Too many negative prejudices.
It would make my life a lot nicer! Maybe we should ask upstream to have a look.
On Tuesday 27 July 2004 14:30, Harry Hoffman wrote:
Yes, Flat text files can be munged pretty bad but the point is that they can only munge themselves. In a registry there is the possibility of editing fsck$#!ing all of the entries (yeah, backups... I know). Still not a good idea :-)
On 2004-07-27 (Tuesday) 20:15, Neal D. Becker wrote:
Yes, here's the linux registry topic again. This project looks interesting. Any comments?
<joking>Everyone can buy windows...</joking> Some ideas look good, but: It aims to replace /etc/passwd, /etc/shadow, /etc/groups and so on, but even M$ are moving to LDAP + kerberos. For me it is useless in this case. 'All key-value pairs are stored in clear-text files' - well, what do we have now? Why is it called 'registry'? Even windows users do not like their registry?
Neal D. Becker wrote:
Yes, here's the linux registry topic again. This project looks interesting. Any comments?
I like it, but the problem is that all major Linux distribution would need to support this for this to take off (at the minimum).
Now how can we convince SuSE to dump Yast for this? What about Debian and Gentoo?
I would gladly upgrade my software to conform to a new API if it becomes the defacto standard. Have it distributed on many distributions and I will change my code.
But if only Fedora adopts it, I will not.
Best regards, Hans Deragon -- Consultant en informatique/Software Consultant Deragon Informatique inc. Open source: http://www.deragon.biz http://facil.qc.ca (Promotion du libre) mailto://hans@deragon.biz http://autopoweroff.sourceforge.net (Logiciel)
On Tuesday 27 July 2004 19:15, Neal D. Becker wrote:
Yes, here's the linux registry topic again. This project looks interesting. Any comments?
Yes, many comments!
I think that almost everybody will agree that Linux needs a different approach to store configuration information for the system, applications and users, other than the traditional configuration files under /etc. The problem is that we do not agree how this new approach should look like. Perhaps, everybody agrees that it must be a kind of local centralized system with a common framework for accessing configuration information.
Regarding to this new "Linux Registry" proposal, I see many problems:
* It provides a system namespace but, how the information is organized? Does every application have its own registry subset? What if two or more applications share configuration values? Shall they duplicate configuration information?
* "It is not an alternative to network information systems": fine, but it should take into account that most of the Linux boxes are networked machines, and presumably, centrally managed. So it should provide a (optional) mechanism for the synchronization with a central networked configuration database.
* "It doesn't know a thing about the semantics of each data it stores": this is a bad thing because we cannot validate configuration information. It assumes that the registry administrator knows what he is doing, and people does not makes mistakes when typing.
* It expects to rewrite all the applications to use the new framework. This is not realistic.
I think that "Linux registry" is a nice step in the right direction, but if we have to change /etc, and change a lot of the already existing code, we should try to do it in the right way, and provide a much more powerful solution.
I your are interested, you can take a look to the solution that the quattor project (see http://www.quattor.org) proposes. Quattor has not been designed as a replacement of the /etc directory, but it can be in the future. Among the advantages the quattor's local Configuration Cache Manager (http://hep-proj-grid-fabric-config.web.cern.ch/hep-proj-grid-fabric-config/d...) has with respect of the Linux Registry I can mention:
* It provides a "User Conventions" (http://quattor.web.cern.ch/quattor/documentation/docs/PanUserConventions.pdf) document as a proposal for a standard to how to organize configuration information.
* It provides the NVA-API library (http://hep-proj-grid-fabric-config.web.cern.ch/hep-proj-grid-fabric-config/d...), to read configuration information (current implementation is in Perl)
* It provides a set of wrapper "configuration components" that reads the cached configuration information and create traditional configuration files. This eases the adoption of the new technology.
* It has a high level configuration language (called pan), that uses a much powerful syntax than these key-value pairs to describe configuration information, and it lets the system manager to perform validations (and then, it is compiled into an internal key-value pairs format)
* It can be used in a networked environment to keep the configuration information centralized.
I do not pretend to convice everybody to move to quattor, what I want to say is that we need a much powerful approach that this simple Linux Registry.
Cheers
Yes, here's the linux registry topic again. This project looks interesting. Any comments?
[...]
I do not pretend to convice everybody to move to quattor, what I want to say is that we need a much powerful approach that this simple Linux Registry.
Apple also has a configuration system that might be worth looking at for inspiration. If I remember right, Mac OS X contains a system that allows different backends (local files, network, etc.). In our case we would probably want a manually editable backend by default.
Also, as mentioned by someone else before, GConf has some interesting capabilities. As I understand, GConf also promised eventual multiple backends. One of the neat things about GConf is that applications do not need to be restarted to read configuration changes (no manual kill -HUP). This might be a nice feature for a future configuration system. Unfortunately, I don't think this is the case if the configuration XML files are edited by hand.
Speaking about GConf, if a new system-wide configuration system were developed that contained an equal- or super-set of GConf's features then it could replace GConf in GNOME and be adopted by KDE, etc. That would be a nice side affect of a well engineered system.
-- Mike
On mer, 2004-07-28 at 10:18 -0500, W. Michael Petullo wrote:
Also, as mentioned by someone else before, GConf has some interesting capabilities. As I understand, GConf also promised eventual multiple backends.
GConf promised to be a registry that avoided the maintenance problems of binary backends using XML. What the GConf people forgot is XML *can* be used to create human-readable and editable files (see fontconfig) but this requires some developer love to be true.
It's especially sad to see an app like evolution (which is supposed to be coded by elite Gnome people) abuse gconf files in so many ways they're almost as bad as a serialised binary blobs.
(take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know what I'm talking about).
Cheers,
On Mon, 2004-08-02 at 14:11 +0200, Nicolas Mailhot wrote:
It's especially sad to see an app like evolution (which is supposed to be coded by elite Gnome people) abuse gconf files in so many ways they're almost as bad as a serialised binary blobs.
(take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know what I'm talking about).
So, you're trying to say that it's wrong to use GCONF's XML format to store some more entity-escaped XML? :)
On lun, 2004-08-02 at 10:38 -0400, Konstantin Ryabitsev wrote:
On Mon, 2004-08-02 at 14:11 +0200, Nicolas Mailhot wrote:
It's especially sad to see an app like evolution (which is supposed to be coded by elite Gnome people) abuse gconf files in so many ways they're almost as bad as a serialised binary blobs.
(take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know what I'm talking about).
So, you're trying to say that it's wrong to use GCONF's XML format to store some more entity-escaped XML? :)
I'm saying putting escaped content in a config file does not improve it's overall legibility, yes.
Or are you telling me something like :
<li type="string"> <stringvalue><?xml version="1.0"?> <group uid="1074843510.8797.7@rousalka.dyndns.org" name="Calendriers en ligne" base_uri="webcal://" readonly="no"><source uid="1079266217.12377.0@rousalka.dyndns.org" name=" Calendrier chinois" relative_uri=" icalx.com/public/squiles/Chinese_New_Year.ics">< properties><property name="refresh" value="30"/></properties></source><source uid="1079266945.12377.4@rousalka.dyndns.org" name="F& #xEA;tes" relative_uri=" ical.mac.com/ical/French32Holidays.ics" color="e2f0ef" ><properties><property name="refresh" value="30"/></properties></source><source uid="1079267532.12377.5@rousalka.dyndns.org" name=" Vacances russes" relative_uri=" www.mozilla.org/projects/calendar/caldata/RussianHolidays.ics"> <properties><property name="refresh" value="30"/></properties></source><source uid="1079267823.12377.6@rousalka.dyndns.org" name=" Vacances scolaires" relative_uri=" ical.mac.com/loic_villette/Vacances_Scolaires.ics">< properties><property name="refresh" value="30"/></properties></source><source uid="1087216349.4221.0@ulysse" name="F&#xEA;tes (bis)" relative_uri=" www.mozilla.org/projects/calendar/caldata/FrenchHolidays.ics" color="f0b8b7"><properties><property name=" refresh" value="30"/></properties> </source></group> </stringvalue> </li>
is human-parsable ?
(not to mention the escaped content won't be validated by your average xml engine since it masquerades as text data - stringvalue indeed:()
Cheers,
On Mon, 2004-08-02 at 17:23 +0200, Nicolas Mailhot wrote:
I'm saying putting escaped content in a config file does not improve it's overall legibility, yes.
Or are you telling me something like :
<skipped/>
is human-parsable ?
Sure! I can tell that you're interested in vacances et calendriers français, chinois, et russes. Not to mention F&#xEA;tes. :)
No, I completely agree with you -- it's a horrible practise, I was just being a smart-ass.
Regards,
On Mon, Aug 02, 2004 at 05:23:39PM +0200, Nicolas Mailhot wrote:
On lun, 2004-08-02 at 10:38 -0400, Konstantin Ryabitsev wrote:
On Mon, 2004-08-02 at 14:11 +0200, Nicolas Mailhot wrote:
It's especially sad to see an app like evolution (which is supposed to be coded by elite Gnome people) abuse gconf files in so many ways they're almost as bad as a serialised binary blobs.
(take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know what I'm talking about).
So, you're trying to say that it's wrong to use GCONF's XML format to store some more entity-escaped XML? :)
I'm saying putting escaped content in a config file does not improve it's overall legibility, yes.
Or are you telling me something like :
[...]
is human-parsable ?
The purpose is not to be human parsable in that case. I don't see that being a programming error at all. It's XML, XML has to be consumed by a parser and parsers have to unescape the piece of text anyway, so I really don't see why you complain. I can give you XML examples which are just readable or unreadable. The key is that it's unicode text.
(not to mention the escaped content won't be validated by your average xml engine since it masquerades as text data - stringvalue indeed:()
If you get the content of the node once parsed and feed it a parser you will get 100% well formedness checking. BTW using "validated" there is a misusage "validating" in XML means checking conformance to a DTD or a schemas. It's precisely to be able to validate the gconf data that you need to put it as a blob inside a TEXT or CDATA section. Perfectly legitimate code in that specific case (gconf backend could be anything, LDAP, database, whatever), what is important is the functionnality of gconf independantly of the backend.
I'm very annoying w.r.t. XML design rules but in that case it just make sense, sorry.
Daniel
On Mon, 2004-08-02 at 14:11 +0200, Nicolas Mailhot wrote:
On mer, 2004-07-28 at 10:18 -0500, W. Michael Petullo wrote:
Also, as mentioned by someone else before, GConf has some interesting capabilities. As I understand, GConf also promised eventual multiple backends.
GConf promised to be a registry that avoided the maintenance problems of binary backends using XML. What the GConf people forgot is XML *can* be used to create human-readable and editable files (see fontconfig) but this requires some developer love to be true.
It's especially sad to see an app like evolution (which is supposed to be coded by elite Gnome people) abuse gconf files in so many ways they're almost as bad as a serialised binary blobs.
(take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know what I'm talking about).
It's XML stored as a string key inside the GConf backend, so you get XML escaped inside XML. Reminds me alarmingly of RSS :-(
Still, it's not quite as bad as a binary blob - at least you have a snowball's chance in hell of figuring it out.
I hope I can get this fixed for Evolution 2.2
On Mon, Aug 02, 2004 at 11:44:42AM -0400, David Malcolm wrote:
On Mon, 2004-08-02 at 14:11 +0200, Nicolas Mailhot wrote:
On mer, 2004-07-28 at 10:18 -0500, W. Michael Petullo wrote:
Also, as mentioned by someone else before, GConf has some interesting capabilities. As I understand, GConf also promised eventual multiple backends.
GConf promised to be a registry that avoided the maintenance problems of binary backends using XML. What the GConf people forgot is XML *can* be used to create human-readable and editable files (see fontconfig) but this requires some developer love to be true.
It's especially sad to see an app like evolution (which is supposed to be coded by elite Gnome people) abuse gconf files in so many ways they're almost as bad as a serialised binary blobs.
(take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know what I'm talking about).
It's XML stored as a string key inside the GConf backend, so you get XML escaped inside XML. Reminds me alarmingly of RSS :-(
Still, it's not quite as bad as a binary blob - at least you have a snowball's chance in hell of figuring it out.
I hope I can get this fixed for Evolution 2.2
I don't see the problem. If that piece of XML need to be stored in gconf it's just fine. The fact that the serialization looks taht way is not a problem in that case. Contrary to RSS, gconf is not about sharing structured content but about an API to a persistant storage, nothing need to be fixed there, it's like storing a template in a database, your database API is "load/store text" then on top of it you apply the specific semantic for the specific case where that text is XML.
Daniel
On mar, 2004-08-03 at 11:48 -0400, Daniel Veillard wrote:
On Mon, Aug 02, 2004 at 11:44:42AM -0400, David Malcolm wrote:
It's XML stored as a string key inside the GConf backend, so you get XML escaped inside XML. Reminds me alarmingly of RSS :-(
Still, it's not quite as bad as a binary blob - at least you have a snowball's chance in hell of figuring it out.
I hope I can get this fixed for Evolution 2.2
I don't see the problem. If that piece of XML need to be stored in gconf it's just fine.
It's not - one of the selling points of gconf was it was "better" than the windows registry because it used a text backend and people could fix stuff manually using their preferred text editor when they had to.
(and BTW I didn't find those files because I wanted to shame anyone but because I had to perform such a manual fix myself).
People *explicitely* asked for something that was not accessed using only some special APIS ie gconf is *not* a black-box storage where you put stuff in random format just because it's convenient.
That piece of XML is largely un-editable be it in vi, emacs or even gconf-editor. It is a problem (_now_).
Cheers,
On Tue, Aug 03, 2004 at 06:07:11PM +0200, Nicolas Mailhot wrote:
It's not - one of the selling points of gconf was it was "better" than the windows registry because it used a text backend and people could fix stuff manually using their preferred text editor when they had to.
(and BTW I didn't find those files because I wanted to shame anyone but because I had to perform such a manual fix myself).
People *explicitely* asked for something that was not accessed using only some special APIS ie gconf is *not* a black-box storage where you put stuff in random format just because it's convenient.
That piece of XML is largely un-editable be it in vi, emacs or even gconf-editor. It is a problem (_now_).
It is not binary. It is editable in case of problem, but you have to understand the data being stored and why it's that way. Sorry to me this is still fullfilling the initial goal. This is escaping not binarization, the rule is simple. Would you suggest that only French text be stored as gconf strings because that's the only ones users would be able to understand and fix ? No this doesn't make sense. Same argument in this case, if you're minimally fluent in XML then why it's escaped and how to fix it if needed is possible.
Daniel
On mer, 2004-08-04 at 04:42 -0400, Daniel Veillard wrote:
It is not binary. It is editable in case of problem, but you have to understand the data being stored and why it's that way. Sorry to me this is still fullfilling the initial goal. This is escaping not binarization, the rule is simple. Would you suggest that only French text be stored as gconf strings because that's the only ones users would be able to understand and fix ? No this doesn't make sense. Same argument in this case, if you're minimally fluent in XML then why it's escaped and how to fix it if needed is possible.
The correct analogy would be to use french key name/values in config files and yes I *would* expect users to be incensed because I choose to use nonsensical (for them) values in a config files. (well french is not a perfect example since it's a western european language - russian would be a better one).
Conf files are not supposed to be computer-friendly only. Conf files are exposed to the user/admin and need the same love as the UI for example.
(and BTW this is not an attack on XML - I breathe XML these days. But there are lots of ways to use XML in conf files that do not make human intervention as difficult as here. Rule one being avoiding entities like the plague they are. Being good computer XML is not sufficient here.)
I do not consider all the efforts exim, postfix... spent on replacing sendmail configuration hell by something more human-friendly wasted. I'm sure lots of people can read sendmail files in the text.
Regards,
On Tue, 2004-08-03 at 11:48 -0400, Daniel Veillard wrote:
On Mon, Aug 02, 2004 at 11:44:42AM -0400, David Malcolm wrote:
On Mon, 2004-08-02 at 14:11 +0200, Nicolas Mailhot wrote:
On mer, 2004-07-28 at 10:18 -0500, W. Michael Petullo wrote:
Also, as mentioned by someone else before, GConf has some interesting capabilities. As I understand, GConf also promised eventual multiple backends.
GConf promised to be a registry that avoided the maintenance problems of binary backends using XML. What the GConf people forgot is XML *can* be used to create human-readable and editable files (see fontconfig) but this requires some developer love to be true.
It's especially sad to see an app like evolution (which is supposed to be coded by elite Gnome people) abuse gconf files in so many ways they're almost as bad as a serialised binary blobs.
(take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know what I'm talking about).
It's XML stored as a string key inside the GConf backend, so you get XML escaped inside XML. Reminds me alarmingly of RSS :-(
Still, it's not quite as bad as a binary blob - at least you have a snowball's chance in hell of figuring it out.
I hope I can get this fixed for Evolution 2.2
I don't see the problem. If that piece of XML need to be stored in gconf it's just fine. The fact that the serialization looks taht way is not a problem in that case. Contrary to RSS, gconf is not about sharing structured content but about an API to a persistant storage, nothing need to be fixed there, it's like storing a template in a database, your database API is "load/store text" then on top of it you apply the specific semantic for the specific case where that text is XML.
Now, storing the various values in one big blob has the property that changes and updates are atomic, and changing that could be a pain.
I think my main objection is that the UI for the gconf-editor is only really set up for dealing with short strings. Trying to locate a particular XML-ified object in the list is really hard in the UI, since there's no extraneous whitespace in the XML and the distinguishing attributes are hidden in a region you have to use scrollbars to navigate to (for each one in the list). As an example, use the gconf-editor and browse to /apps/evolution/calendar/sources, and, assuming you have a large number of calendars set up, try to figure out which is which.
So if we accept that people are going to store XML-ified representations of objects into GConf as strings - then the GConf tools need to provide support for it. For example, syntax-highlighting, maybe an option to pretty-print a tree view of the XML (maybe even a mini XML-editor in place).
Or maybe adding some judicious whitespace to the object serialisation could help alleviate the readability/distinguishability.
Daniel
-- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Wed, Aug 04, 2004 at 11:28:35AM -0400, David Malcolm wrote:
Now, storing the various values in one big blob has the property that changes and updates are atomic, and changing that could be a pain.
I think my main objection is that the UI for the gconf-editor is only really set up for dealing with short strings. Trying to locate a particular XML-ified object in the list is really hard in the UI, since there's no extraneous whitespace in the XML and the distinguishing attributes are hidden in a region you have to use scrollbars to navigate to (for each one in the list). As an example, use the gconf-editor and browse to /apps/evolution/calendar/sources, and, assuming you have a large number of calendars set up, try to figure out which is which.
So if we accept that people are going to store XML-ified representations of objects into GConf as strings - then the GConf tools need to provide support for it. For example, syntax-highlighting, maybe an option to pretty-print a tree view of the XML (maybe even a mini XML-editor in place).
Well, it becomes a type system issue. Do you want to expand the type system of gconf to understand XML instance or just keep as strings. That's an issue that came all the time as soon as people tried to store XML (or markup in general) within databases. Do you really have a gconf limit on the length of strings stored ? Do you also have a limit on the character set (and encodings) allowed. I don't think adding an XML type will gain much in practice, and it will cost a lot. if the structure of the information isn't reflected in the way it's stored, then that simply mean that it's not pertinent to check it at that level. For editing, as long as your cut and paste works correctly then any good XML editor will be better than what you can cook in the boundaries of the GConf tools, and using that should be way better.
Or maybe adding some judicious whitespace to the object serialisation could help alleviate the readability/distinguishability.
please don't whitespaces are significant in XML, and would break any attemps at signing a key value.
Daniel
On Wed, 2004-08-04 at 12:39 -0400, Daniel Veillard wrote:
On Wed, Aug 04, 2004 at 11:28:35AM -0400, David Malcolm wrote:
Now, storing the various values in one big blob has the property that changes and updates are atomic, and changing that could be a pain.
I think my main objection is that the UI for the gconf-editor is only really set up for dealing with short strings. Trying to locate a particular XML-ified object in the list is really hard in the UI, since there's no extraneous whitespace in the XML and the distinguishing attributes are hidden in a region you have to use scrollbars to navigate to (for each one in the list). As an example, use the gconf-editor and browse to /apps/evolution/calendar/sources, and, assuming you have a large number of calendars set up, try to figure out which is which.
So if we accept that people are going to store XML-ified representations of objects into GConf as strings - then the GConf tools need to provide support for it. For example, syntax-highlighting, maybe an option to pretty-print a tree view of the XML (maybe even a mini XML-editor in place).
Well, it becomes a type system issue. Do you want to expand the type system of gconf to understand XML instance or just keep as strings. That's an issue that came all the time as soon as people tried to store XML (or markup in general) within databases. Do you really have a gconf limit on the length of strings stored ?
No, the limit is on what I can use comfortably within the GUI; it's a factor of this aging coder, rather than the architecture :-)
Do you also have a limit on the character set (and encodings) allowed. I don't think adding an XML type will gain much in practice, and it will cost a lot. if the structure of the information isn't reflected in the way it's stored, then that simply mean that it's not pertinent to check it at that level. For editing, as long as your cut and paste works correctly then any good XML editor will be better than what you can cook in the boundaries of the GConf tools, and using that should be way better.
Or maybe adding some judicious whitespace to the object serialisation could help alleviate the readability/distinguishability.
please don't whitespaces are significant in XML, and would break any attemps at signing a key value.
What I meant was to add whitespace in the particular app that generates the XML, in places where that app doesn't care about it when it later reads the XML back in. Although there's no actual DTD, the one implied by the code has plenty of places where whitespace PCDATA in instance documents is redundant.
The GConf side of things would faithfully preserve any whitespace; I wasn't proposing to do any manipulation there; that would suck.
Daniel
Neal D. Becker wrote:
Yes, here's the linux registry topic again. This project looks interesting. Any comments?
One motivation that I didn't hear anyone mention:
It is difficult to add entries/edit a flat file. It is easy to add modify a structure, such as a directory. This is becoming increasing used for example, /etc/cron.daily. Package management is much easier this way. There are many other examples like this.
Any new scheme should follow a model which includes this property. It is (theoretically) possible to achieve the same semantics by other schemes (not necessarily directories with files in a real filesystem). OTOH, I am not advocating for inventing yet another virtual filesystem for this purpose.
On Wed, 2004-07-28 at 17:56, Neal D. Becker wrote:
Neal D. Becker wrote:
Yes, here's the linux registry topic again. This project looks interesting. Any comments?
One motivation that I didn't hear anyone mention:
It is difficult to add entries/edit a flat file.
^^^Bingo !!! Somebody else hits the nail on the head
Hence the need for "A COMMON API FOR MANIPULATING TEXT IN FLAT FILES"
I've written a utility in plain'Ol C. Its got two functions for reading and writing flat file config files and a utility that uses them. I'm not suggesting this become a standard, but something like it should exist in the core libs??
This is the same type of code I see done over and over again because its missing from the core API for Unix.
My util.... ******** [root@localhost onsight-utils]# readwriteconfig
readwriteconfig -r filename variable readwriteconfig -w filename variable=value
Examples: readwriteconfig -w /etc/sysconfig/networking/profiles/default/ifcfg-eth0 IPADDR=192.168.1.113
Writing will return a single character A=appended C=Changed N=File to large. Reading will return the variables value only or nothing if the string is not found
[root@localhost onsight-utils]#
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
My util....
[root@localhost onsight-utils]# readwriteconfig
readwriteconfig -r filename variable readwriteconfig -w filename variable=value
Examples: readwriteconfig -w /etc/sysconfig/networking/profiles/default/ifcfg-eth0 IPADDR=192.168.1.113
Writing will return a single character A=appended C=Changed N=File to large. Reading will return the variables value only or nothing if the string is not found
[root@localhost onsight-utils]#
So post the source boyo - -- Public Key available Here: http://www.bravegnuworld.com/~rjune/rjune.asc
Jonathan Andrews wrote:
On Wed, 2004-07-28 at 17:56, Neal D. Becker wrote:
Neal D. Becker wrote:
Yes, here's the linux registry topic again. This project looks interesting. Any comments?
One motivation that I didn't hear anyone mention:
It is difficult to add entries/edit a flat file.
^^^Bingo !!! Somebody else hits the nail on the head
Hence the need for "A COMMON API FOR MANIPULATING TEXT IN FLAT FILES"
I've written a utility in plain'Ol C. Its got two functions for reading and writing flat file config files and a utility that uses them. I'm not suggesting this become a standard, but something like it should exist in the core libs??
This is the same type of code I see done over and over again because its missing from the core API for Unix.
My util....
[root@localhost onsight-utils]# readwriteconfig
readwriteconfig -r filename variable readwriteconfig -w filename variable=value
Examples: readwriteconfig -w /etc/sysconfig/networking/profiles/default/ifcfg-eth0 IPADDR=192.168.1.113
Writing will return a single character A=appended C=Changed N=File to large. Reading will return the variables value only or nothing if the string is not found
[root@localhost onsight-utils]#
I think you have an interesting idea. Problem is, it would have to assume a particular structure/format for the file.
Now, suppose you combine your editor (that's what I'm calling your util) with a pluggable language to describe the format. Then you can keep the existing config files as they are, don't modify the client programs, yet have a common front end to do the configuration. But then, isn't that what Yast and friends are already doing?
On Wed, 2004-07-28 at 18:06 +0100, Jonathan Andrews wrote:
On Wed, 2004-07-28 at 17:56, Neal D. Becker wrote:
Neal D. Becker wrote:
Yes, here's the linux registry topic again. This project looks interesting. Any comments?
One motivation that I didn't hear anyone mention:
It is difficult to add entries/edit a flat file.
^^^Bingo !!! Somebody else hits the nail on the head
Hence the need for "A COMMON API FOR MANIPULATING TEXT IN FLAT FILES"
So, if it's difficult to manage flat files, then I could argue that we don't want flat files, which invalidates the previous arguments. Maybe we could use structured files, like XML or hierarchical backends. But this depends on the nature of the information being stored and the nature of the application using it.
Once again, I can't think of a one-site-fits-all scheme. That's the beauty of UNIX: diversite, and choosing the best tool that fits your need.
[root@localhost onsight-utils]#
So post the source boyo
Source available.
Im not claiming its good!
http://www.jonshouse.co.uk/readwriteconfig.tar.gz
Jon
On Jul 28, 2004, Jonathan Andrews jon@jonshouse.co.uk wrote:
On Wed, 2004-07-28 at 17:56, Neal D. Becker wrote:
One motivation that I didn't hear anyone mention:
It is difficult to add entries/edit a flat file.
^^^Bingo !!! Somebody else hits the nail on the head
Hence the need for "A COMMON API FOR MANIPULATING TEXT IN FLAT FILES"
Err... How does this help solve the problem of an rpm package owning only part of such a flat text file?
Neal D. Becker wrote:
Yes, here's the linux registry topic again. This project looks interesting. Any comments?
Wouldn't a cleanup of /etc be a nice start. This could be don quite simply by grouping together relevant configuration files, such as network related configs in on directory (possible with subdirectories):
/etc /etc/application/ /etc/network/ /etc/server/ ....
For instance, what now is commonly in /etc/httpd should be placed in /etc/server/httpd, /etc/resolv.conf in /etc/network, I hope you get the idea...
I don't tink that anyone should be forced into using this scheme, but if a newly installed Fedora has all the configuration files tugged nicely in relevant folders, people might follow it...
And I think this scheme isn't as difficult to implement, as the Grand Unified Registry would be, as many programs let you define the placement of the config file, when they are buildt...
My 25cents /kbn
devel@lists.stg.fedoraproject.org
-
Alan Cox -
Alexandre Oliva -
Chris Adams -
Dan Williams -
Daniel Veillard -
David Hollis -
David Malcolm -
Doncho N. Gunchev -
Felipe Alfaro Solana -
Florin Andrei -
Hans Deragon -
Harry Hoffman -
Jef Spaleta -
Jeremy Katz -
John Hearns -
John W. Linville -
Jonathan Andrews -
Kenneth Porter -
Kim B. Nielsen -
Konstantin Ryabitsev -
Mark Heslep -
Matthew Miller -
Michael Favia -
Neal Becker -
Nicolas Mailhot -
Rafael Garcia Leiva -
Remco Treffkorn -
Rex Dieter -
Richard June -
Stan Bubrouski -
Steve Brenneis -
W. Michael Petullo