On Tue, Mar 28, 2006 at 12:30:43PM -0500, sean wrote:
gconf isn't limited because of its file format. It's limited because it's tied so closely to the Gnome WM. Really, once you have a standard
Gconf doesn't need gnome. The reverse is true however. The XML format also lets you work with prefences using styles and XML XSLT and the like which is very powerful when working with a large number of systems. Really nobody has scratched the surface of what it can do.
You don't have to care about the XML either, one of the crazier gconf demos from a long time ago was an email interface to gconf settings
On Tue, 28 Mar 2006, Alan Cox wrote:
Gconf doesn't need gnome. The reverse is true however. The XML format also lets you work with prefences using styles and XML XSLT and the like which is very powerful when working with a large number of systems. Really nobody has scratched the surface of what it can do.
http://www.libelektra.org/GConf has a whole list of reasons why they feel gconf would be a bad choice (at least in its current form) for the system configuration api. A few example it has a lot more library dependencies, was not designed with a global namespace in mind, "GConf storage backend uses XML files, which are big, take long time and system resources to parse or update.", Eletkra has the concepts of "backends" of which gconf is one.
I dunno if Elektra is the right solution, but they seem to have some good arguments.
Shane
On 3/28/06, Shane Stixrud shane@geeklords.org wrote:
I dunno if Elektra is the right solution, but they seem to have some good arguments.
whether or not elektra is the right solution will be decided by whether or not individual upstream software projects start working towards integrating support for elektra as their default configuration scheme. This sort of technology revolution is not going to be crowbarred into applications by Fedora or any sane distributor that needs to worry about keeping in sync with upstream project developements. If you can't convince upstream developers to build in support, a think its pretty ludicrious to be having a discussion about it at the distributor level with any expectation a distributor like fedora to do all the work downstream to integrate electra specific patches. The elektra developers might believe they've got the best idea for a technology since sliced bread... but what existing projects with an active codebase are actually attempting to integrate support for this concept into their application?
And why are they bothering with SysVinit at all... when there are a chorus of voices whoaare calling for SysVinit to be shot in the head. If electra were smart they'd be in communication with developers of a few of the up and coming SysVinit replacements... cough initng cough... and get elektra support buried deep into the guts of those projects so elektra gets dragged in because it would take too much work to remove.
-jef"can someone point me to the upstream xorg discussion where the elektra people have submitted their patches for inclusion into the mainline xorg codebase?"spaleta
On Tue, 28 Mar 2006, Jeff Spaleta wrote:
whether or not elektra is the right solution will be decided by whether or not individual upstream software projects start working towards integrating support for elektra as their default configuration scheme.
This reasoning is flawed and I think it illustrates an example of where our Darwinist Meritocracy has difficultly dealing with problems that are global and counter to our evolutionary path. Tell me, what motivators exist for any project or even groups of projects to adapt a non-standard 3rd parties configuration schema?? None, in fact I am sure there are plenty of reasons NOT to adapt such a thing. When looking at this issue from within a specific microcosms perspective it makes perfect sense why UNIX and Linux have failed to create this standard API after 40+ years of evolution.
It is when you look at GNU/LINUX as a whole that this problem becomes obvious and it is for this reason I think Fedora/freedesktop/LSB/FHS or some other entity with ties to the system as a whole will have to champion this standard. A global configuration scheme has little benefit until a large portion of the system is using it, until that threshold is meet it is but another configuration format adding to the systems complexity.
And why are they bothering with SysVinit at all...
My guess is because at the time they did the patches this debate was not hot. It seems they treated sysvinit as a proof of concept that libelektra is usable even at the earliest stages of os initialization.
On 3/28/06, Shane Stixrud shane@geeklords.org wrote:
My guess is because at the time they did the patches this debate was not hot. It seems they treated sysvinit as a proof of concept that libelektra is usable even at the earliest stages of os initialization.
everything with regard to elektra is proof of concept at the moment. Is there any upstream project new or old that is attempting to use elektra? Just point me to an upstream discussion for any codebase with a seperate set of lead developers who are working on integrating elektra even as an option for configuration. Is anyone who is responsibly for the mainline development of any application that has configuration files to deal with looking to pick up this technology and run with it? Fedora should not be crowbaring any technological leap which is meant to be a "standard" into old codebases if there isn't even obvious momentum yet with regard to new codebase adoption.
I don't see any upstream project reaching for a solution to what elektra is attempting. At the very least that a very big marketing problem that the elektra project has. Billing yourself as the end all be all of configuration systems.. and you can't get any upstream project developers to see your point? Either you are overblowing the problem or your implementation has some serious flaws or you aren't making an effort to market your technology to the right people. I'm giving elektra the benefit of the doubt when I say their problem is a matter of focusing on the wrong audience. Upstream! Upstream! Upstream! Continuing to bring it up at the distribution level is a good way to never gain traction. Getting an up and coming application to bite the bullet and use your technology moves your project from "proof of concept" to "in use in the wild"
-jef
On Tue, 28 Mar 2006, Jeff Spaleta wrote:
Continuing to bring it up at the distribution level is a good way to never gain traction. Getting an up and coming application to bite the bullet and use your technology moves your project from "proof of concept" to "in use in the wild"
Please don't imply I give one wit if elektra is the correct solution or not, because I don't. My only interest is in discovering why this problem hasn't already been solved and if anyone has a clue as to what the correct solution would look like.
The simple fact is GNU/Linux could do much better on this front and it appears we have no real plan or general consensus on how to proceed to in address this issue on a global scale.
Shane
The simple fact is GNU/Linux could do much better on this front and it appears we have no real plan or general consensus on how to proceed to in address this issue on a global scale.
A full ack on this, we would solve a lot of items if we could move forward to have a standard lib for all this. But it will be very hard to have agreement on how to solve it and even more to make projects move over from their current ways.
regards,
Florian La Roche
On 3/29/06, Florian La Roche laroche@redhat.com wrote:
The simple fact is GNU/Linux could do much better on this front and it appears we have no real plan or general consensus on how to proceed
to
in address this issue on a global scale.
A full ack on this, we would solve a lot of items if we could move forward to have a standard lib for all this. But it will be very hard to have agreement on how to solve it and even more to make projects move over from their current ways.
regards,
Florian La Roche
I think the process of getting other projects to use this "standard" would
be to put some though into the design and mark multiple backends and multiple interfaces part of the design. If there are libs, modules, languages binds, etc with as little dependancy hell as possible, I think projects will eventually gravitate to this solution. I know I wouldn't roll my own config parser if there is a perfectly good one already included on my system , or which can easily be added to any system.
Arthur
-- As a boy I jumped through Windows, as a man I play with Penguins.
On Wed, 29 Mar 2006, Arthur Pemberton wrote:
A full ack on this, we would solve a lot of items if we could move forward to have a standard lib for all this. But it will be very hard to have agreement on how to solve it and even more to make projects move over from their current ways.
I think the process of getting other projects to use this "standard" would be to put some though into the design and mark multiple backends and multiple interfaces part of the design. If there are libs, modules, languages binds, etc with as little dependancy hell as possible, I think projects will eventually gravitate to this solution. I know I wouldn't roll my own config parser if there is a perfectly good one already included on my system , or which can easily be added to any system.
I agree design is key here. However our community generally wants no part of discussing requirements and then writing specifications in English. They want actual code... Is there a good case here for gathering requirements and perhaps writing a specification, getting feedback from the major players prior to code being written?
Cheers, Shane
On 3/29/06, Shane Stixrud shane@geeklords.org wrote:
On Wed, 29 Mar 2006, Arthur Pemberton wrote:
A full ack on this, we would solve a lot of items if we could move forward to have a standard lib for all this. But it will be very hard to have agreement on how to solve it and even more to make projects move over from their current ways.
I think the process of getting other projects to use this "standard"
would
be to put some though into the design and mark multiple backends and multiple interfaces part of the design. If there are libs, modules, languages binds, etc with as little dependancy hell as possible, I think projects will eventually gravitate to this solution. I know I wouldn't
roll
my own config parser if there is a perfectly good one already included
on my
system , or which can easily be added to any system.
I agree design is key here. However our community generally wants no part of discussing requirements and then writing specifications in English. They want actual code... Is there a good case here for gathering requirements and perhaps writing a specification, getting feedback from the major players prior to code being written?
Cheers, Shane
Only case I see here is individual desire. People passioate enough about
this need to solve the problem. I and apperently many others simply do not see this as a big enough problem. I am actually suprised by the length of this thread. Don't get me wrong, I see the problem, and I think I understand it. It just isn't a hurdle I run into often. Now, if we were talking about the sendmail conf files.... -- As a boy I jumped through Windows, as a man I play with Penguins.
On Wed, 29 Mar 2006, Arthur Pemberton wrote:
Only case I see here is individual desire. People passioate enough about this need to solve the problem. I and apperently many others simply do not see this as a big enough problem. I am actually suprised by the length of this thread. Don't get me wrong, I see the problem, and I think I understand it. It just isn't a hurdle I run into often. Now, if we were talking about the sendmail conf files....
I don't really agree. I think the reason you see a number of RedHat employees agreeing that this is important is because there are real issues their enterprise customers want addressed that is either directly or indirectly negatively affected by this more fundamental issue.
Cheers, Shane
On 3/29/06, Shane Stixrud shane@geeklords.org wrote:
On Wed, 29 Mar 2006, Arthur Pemberton wrote:
Only case I see here is individual desire. People passioate enough about this need to solve the problem. I and apperently many others simply do
not
see this as a big enough problem. I am actually suprised by the length
of
this thread. Don't get me wrong, I see the problem, and I think I
understand
it. It just isn't a hurdle I run into often. Now, if we were talking
about
the sendmail conf files....
I don't really agree. I think the reason you see a number of RedHat employees agreeing that this is important is because there are real issues their enterprise customers want addressed that is either directly or indirectly negatively affected by this more fundamental issue.
Cheers, Shane
Ah. Well that is understandable. They certainly have a point of view which
I have not yet had the honor of.
Might I make a suggestion to anyone considerinf "fixing" this. I would suggest the use of virtual files. So for example, program-foo which uses program-foo.conf could attempt to read/parse/saveto program-foo.conf which could be actually a virtual file serving as a front end to a system which handles everything else.
-- As a boy I jumped through Windows, as a man I play with Penguins.
On 3/29/06, Shane Stixrud shane@geeklords.org wrote:
They want actual code... Is there a good case here for gathering requirements and perhaps writing a specification, getting feedback from the major players prior to code being written?
I agree 100% with that. We need to figure out what we want, not how to do it right now. If we can get relative consensus on the features and requirements of a perfect config system then I'm sure someone will step up and get a prototype up and running soon afterward. How best to do that? Wiki page? dunno...
On Tue, 2006-03-28 at 14:43 -0800, Shane Stixrud wrote:
Please don't imply I give one wit if elektra is the correct solution or not, because I don't. My only interest is in discovering why this problem hasn't already been solved and if anyone has a clue as to what the correct solution would look like.
I'm still not convinced that there's a problem in need of solving here.
(XML is like violence, if it doesn't help, use more)
On Sat, 1 Apr 2006, Callum Lerwick wrote:
On Tue, 2006-03-28 at 14:43 -0800, Shane Stixrud wrote:
Please don't imply I give one wit if elektra is the correct solution or not, because I don't. My only interest is in discovering why this problem hasn't already been solved and if anyone has a clue as to what the correct solution would look like.
I'm still not convinced that there's a problem in need of solving here.
What would it take to convince you?
The limitations around automating/scripting system changes without replacing whole config files is one problem. How about the differing syntax between most applications without a technical need, some of which have horrid syntax. The impracticality of programs sharing configuration elements with each other without each application being aware of every other applications magic syntax. The impossibility of having an automated system for saving and reverting changes without saving whole config files after every change and then figuring out what changed and why. Or how about the fact developing configuration guis/tools is many orders of magnitude more difficult when their is no consistent config file standard?
Shane.
On Sat, 2006-04-01 at 19:29 -0800, Shane Stixrud wrote:
What would it take to convince you?
The limitations around automating/scripting system changes without replacing whole config files is one problem. How about the differing syntax between most applications without a technical need, some of which have horrid syntax. The impracticality of programs sharing configuration elements with each other without each application being aware of every other applications magic syntax. The impossibility of having an automated system for saving and reverting changes without saving whole config files after every change and then figuring out what changed and why. Or how about the fact developing configuration guis/tools is many orders of magnitude more difficult when their is no consistent config file standard?
Look at Debian if you want to see how config files should be handled.
Judicious use of conf.d type directories goes a long way.
Fedora's own /etc/sysconfig hierarchy is a good example of how config files can be brain dead simple, hand editable and GUI configurable.
On Sun, 2 Apr 2006, Callum Lerwick wrote:
On Sat, 2006-04-01 at 19:29 -0800, Shane Stixrud wrote:
What would it take to convince you?
The limitations around automating/scripting system changes without replacing whole config files is one problem. How about the differing syntax between most applications without a technical need, some of which have horrid syntax. The impracticality of programs sharing configuration elements with each other without each application being aware of every other applications magic syntax. The impossibility of having an automated system for saving and reverting changes without saving whole config files after every change and then figuring out what changed and why. Or how about the fact developing configuration guis/tools is many orders of magnitude more difficult when their is no consistent config file standard?
Look at Debian if you want to see how config files should be handled.
Judicious use of conf.d type directories goes a long way.
Does not address any of the above in any significant way... in other words I fail to see your point.
Fedora's own /etc/sysconfig hierarchy is a good example of how config files can be brain dead simple, hand editable and GUI configurable.
Awww we agree! Considering that ALL of RedHat's sysconfig config files are basically KEYS with values how could I not? If you give sysconfig a bit more structure (directories), have the directory names themselves be part of the syntax/semantics and standardized the creation/removal/modification/searching and querying of these files in the form of a library we end up with....... Elektra
....
Shane
On 4/2/06, Shane Stixrud shane@geeklords.org wrote:
On Sun, 2 Apr 2006, Callum Lerwick wrote:
Fedora's own /etc/sysconfig hierarchy is a good example of how config files can be brain dead simple, hand editable and GUI configurable.
Awww we agree! Considering that ALL of RedHat's sysconfig config files are basically KEYS with values how could I not? If you give sysconfig a bit more structure (directories), have the directory names themselves be part of the syntax/semantics and standardized the creation/removal/modification/searching and querying of these files in the form of a library we end up with....... Elektra
And /etc/sysconfig is RH-specific only, as far as I know. At least the semantics inside each /etc/sysconfig file. And they imply spliting the configurations of some programs in two parts. For example, ntpd has the /etc/ntp.conf and the /etc/sysconfig/ntpd files. This happens precisely because is very difficult to change these software configurations directly on their files, so distros were forced to create a secondary file and a separate whole scripting system to handle them too.
On Sun, 2 Apr 2006, Avi Alkalay wrote:
And /etc/sysconfig is RH-specific only, as far as I know.
It's from IRIX (just called /etc/default?). Solaris has it too.
regards,
On Sat, 2006-04-01 at 19:29 -0800, Shane Stixrud wrote:
What would it take to convince you?
What would convince me is, as they say in XP, is some detailed UserStories explaining what exactly it is you want to do, and why you can't do it now. Instead of vague handwaving.
On Sun, 2 Apr 2006, Callum Lerwick wrote:
On Sat, 2006-04-01 at 19:29 -0800, Shane Stixrud wrote:
What would it take to convince you?
What would convince me is, as they say in XP, is some detailed UserStories explaining what exactly it is you want to do, and why you can't do it now. Instead of vague handwaving.
Have you not been paying attention then? They have been outlined in multiple posts, in multiple ways. If you want a more detailed outlined E-mail me off list so others don't have to see the same ground being covered yet again.
Shane
Shane Stixrud shane@geeklords.org wrote:
On Sun, 2 Apr 2006, Callum Lerwick wrote:
On Sat, 2006-04-01 at 19:29 -0800, Shane Stixrud wrote:
What would it take to convince you?
What would convince me is, as they say in XP, is some detailed UserStories explaining what exactly it is you want to do, and why you can't do it now. Instead of vague handwaving.
Have you not been paying attention then?
I sure have.
They have been outlined
The operating word being _outlined_... in vague terms, like complaining about formats in general (no examples!), that some (unspecified!) automatic handling isn't done today, that people have a hard time reading configuration files (with no details on which ones, exactly, and who/why/for what).
inmultiple posts, in multiple ways. If you want a more detailed outlined E-mail me off list so others don't have to see the same ground being covered yet again.
Please don't. This clearly goes nowhere.
Le samedi 01 avril 2006 à 19:29 -0800, Shane Stixrud a écrit :
The limitations around automating/scripting system changes without replacing whole config files is one problem. How about the differing syntax between most applications without a technical need, some of which have horrid syntax. The impracticality of programs sharing configuration elements with each other without each application being aware of every other applications magic syntax. The impossibility of having an automated system for saving and reverting changes without saving whole config files after every change and then figuring out what changed and why. Or how about the fact developing configuration guis/tools is many orders of magnitude more difficult when their is no consistent config file standard?
Shane,
I'm not saying all your points are not a problem. But in the big picture they're not *the* problem.
Software design is a balance between the needs of the software writer, and the needs of the software user. Configuration files are already used to transfer some of the work from the software writer to the software user (if the software was perfect and the software writer omnicient there would be no need for config files).
You propose to make the transfer even easier with some new infrastructure. (easier on the software writer that is). But the current configuration pains stem not because this transfer is painful (adding a conf entry has always been less work for a software writer than figuring the right value or autodetect algorithm). They stem from software writers dumping ill-though keys on users. And here you'll make the situation even worse, by promoting a no-need-to-think configuration system (see the post on the new printing admin tool in the archives - problem not the conf file syntax but that key values/names are inconsistent).
A case in point is gconf where the work is already so little on the software writer part some apps have been known to dump serialized structures in conf files, and the Gnome people insistence on hiding most of the keys from users has led on a pile of crapload files (why bother thinking if users never see the keys ? except problems happen and user need to salvage systems).
Sendmail is another perfect example where configuration has been optimized for the software, not the humans and that's the #1 sendmail rejection factor today
On Sun, 2 Apr 2006, Nicolas Mailhot wrote:
writers dumping ill-though keys on users. And here you'll make the situation even worse, by promoting a no-need-to-think configuration system (see the post on the new printing admin tool in the archives - problem not the conf file syntax but that key values/names are inconsistent).
This is just not true. Nothing about standardizing configuration data makes the system a "no-need-to-think configuration system". It's just the opposite in fact, the user is is now free to THINK and FOCUS on the FUNCTION they wish to perform with less needless distraction.
Cheers, Shane
Le dimanche 02 avril 2006 à 03:57 -0700, Shane Stixrud a écrit :
On Sun, 2 Apr 2006, Nicolas Mailhot wrote:
writers dumping ill-though keys on users. And here you'll make the situation even worse, by promoting a no-need-to-think configuration system (see the post on the new printing admin tool in the archives - problem not the conf file syntax but that key values/names are inconsistent).
This is just not true. Nothing about standardizing configuration data makes the system a "no-need-to-think configuration system".
That's just sooo untrue. A software writer will just spend more time on features which he considers expensive in developer time. You need to take the human factor into account. FOSS like many other software changes relied heavily on social not technical factors.
It's just the opposite in fact, the user is is now free to THINK and FOCUS on the FUNCTION they wish to perform with less needless distraction.
Again, if you think the problem is on the user side you've already lost it.
On Sun, 2 Apr 2006, Nicolas Mailhot wrote:
Again, if you think the problem is on the user side you've already lost it.
That's interesting.... others said the problem was on the user side... and you are saying its on the programmers side...
In truth its a win for both, it is just counter to our UNIX traditions, ourunix history and our unix emotional^H^H^H^H^H^H^H^H^H social attachments.
Cheers, Shane
Le dimanche 02 avril 2006 à 04:34 -0700, Shane Stixrud a écrit :
On Sun, 2 Apr 2006, Nicolas Mailhot wrote:
Again, if you think the problem is on the user side you've already lost it.
That's interesting.... others said the problem was on the user side... and you are saying its on the programmers side...
The problem is on the user side The solution is on the programmers side.
Which is why analysing the problem from the software writer POW (generic API) won't get us anywhere
On Sun, 2 Apr 2006, Nicolas Mailhot wrote:
Again, if you think the problem is on the user side you've already lost it.
That's interesting.... others said the problem was on the user side... and you are saying its on the programmers side...
The problem is on the user side The solution is on the programmers side.
Which is why analysing the problem from the software writer POW (generic API) won't get us anywhere
Now you are just talking double talk.
What is YOUR solution for a unversal process for managing / editing configuration files programatically? (Let me guess, hand over eyes... what problem??)
How can we improve revision control for system config changes (Let me guess, isn't that what tape backups are for?).
How can we improve the documentation of what configuration changes have been made and why. i.e. the "receipy" for a given systems functionality. (Let me guess, isn't that what tape backups and 3 ring binders are for?).
Can we have a Linux configuration system that predictable and editable with simple methods/tools where these methods/tools do not need to change based on how applications decide to layout their config data (Let me guess, NO, that is crazy talk.....)
Cheers, Shane
On Sun, Apr 02, 2006 at 11:50:35AM -0700, Shane Stixrud wrote:
What is YOUR solution for a unversal process for managing / editing configuration files programatically? (Let me guess, hand over eyes... what problem??)
Cfengine does that, but it's crude. Puppet is going to go one step further and hide some of the details.
There is simply no silver bullet.
On Sun, 2 Apr 2006, Rudi Chiarito wrote:
On Sun, Apr 02, 2006 at 11:50:35AM -0700, Shane Stixrud wrote:
What is YOUR solution for a unversal process for managing / editing configuration files programatically? (Let me guess, hand over eyes... what problem??)
Cfengine does that, but it's crude. Puppet is going to go one step further and hide some of the details.
My reading of puppet suggested it still deals in config file replacement. If thats so its usefulness is largely offset by the overhead of managing and documenting the puppet backend. When all is said and done any system that merely pushes files to managed devices, oblivious of the changes within those files is kludgey at best.
There is simply no silver bullet.
Of course not, but there solid approaches to shooting this problem dead. It is just not east to get there from here.
Cheers, Shane
On Sun, 2 Apr 2006, Avi Alkalay wrote:
This thread has gotten off track IMO. Does anyone care to critique Elektra from a technical stand point on its suitability as a Fedora configuration engine?
So far the technical critiques have been based on invalid assumptions.
Cheers, Shane
As far as I can tell Elektra does not support configuration schemas.
For me that would be an important *option* that an application developer can avail of. The schema can make sure that silly errors are reduced (ie that integers are integers, IP addresses are IP addresses, etc). The schema can also incorporate hits to a GUI editor (eg appropriate widget to use, help text in various languages etc).
With a schema you get a user friendly and robust GUI configuration tool for free (ok -- that may not apply to complex applications, but it would cover at least 80% of applications I think).
Joe.
On 4/2/06, Shane Stixrud shane@geeklords.org wrote:
On Sun, 2 Apr 2006, Avi Alkalay wrote:
This thread has gotten off track IMO. Does anyone care to critique Elektra from a technical stand point on its suitability as a Fedora configuration engine?
So far the technical critiques have been based on invalid assumptions.
Cheers, Shane
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Sun, 2 Apr 2006, Joe Desbonnet wrote:
As far as I can tell Elektra does not support configuration schemas.
If I am not mistaken Elektra currently treats all plain text key values as strings. I think this is a feature and not a limitation. Elektra is friendly towards existing application configuration schemes. If it enforced key types (Integers, floats, strings etc...) things get a lot more complicated and it is not clear this is the right place to enforce it.
Perhaps enforcing the input types at a configuration builder API makes more sense, keeping libelektra free of the added complexity?
Cheers, Shane
On 4/2/06, Shane Stixrud shane@geeklords.org wrote:
On Sun, 2 Apr 2006, Avi Alkalay wrote:
This thread has gotten off track IMO. Does anyone care to critique Elektra from a technical stand point on its suitability as a Fedora configuration engine?
So far the technical critiques have been based on invalid assumptions.
Exactly. Since Elektra was designed to absolutely any type of software, even to no-software, we tryed to keep it as simple as possible. The more we optimize it for some specific need, we deoptimize it for some other.
However, you can put some layer of schematics on top of it. This is exactly what GConf with Elektra as its backend is: use GConf API, GConf namespaces, GConf semantics, GConf schemas, and Elektra only for the storage and sharing with everybody else (KDE, etc).
I personally think schemas add too much complexity to the application programmer, make his life more difficult, and inhibits him to interact with other softwares configurations. But this is my opinion and we don't have to discuss that....
Avi
On 4/2/06, Shane Stixrud shane@geeklords.org wrote:
On Sun, 2 Apr 2006, Joe Desbonnet wrote:
As far as I can tell Elektra does not support configuration schemas.
If I am not mistaken Elektra currently treats all plain text key values as strings. I think this is a feature and not a limitation. Elektra is friendly towards existing application configuration schemes. If it enforced key types (Integers, floats, strings etc...) things get a lot more complicated and it is not clear this is the right place to enforce it.
Perhaps enforcing the input types at a configuration builder API makes more sense, keeping libelektra free of the added complexity?
Cheers, Shane
Oh, and for anybody that wants to try Elektra, Fedora/RHEL/CentOS RPMs are available here:
http://sourceforge.net/project/showfiles.php?group_id=117521
(There are some patches to X.org and /sbin/init there too. Patches to other softwares can be found in Elektra source tree)
Don't forget to download kdbedit too, for a GUI experience:
http://sourceforge.net/project/showfiles.php?group_id=117521&package_id=...
Avi
Strings would be a sensible default in the absense of a schema, but I think you could do so much more if you had the *option* to have a schema in the infrastructure.
For each field the schema would define the data type (string, integer, date, ip, username, enum etc), constrains on the values (eg "must be integer between 1-5"), a help text or hyperlink to help, and GUI hints (eg widget preferences: pulldown menu vs radio buttons, tab groupings etc).
So instead of a system-config-blah for each application, you just have one system-config tool that autogenerates a GUI based on schema.
Joe.
On 4/3/06, Shane Stixrud shane@geeklords.org wrote:
If I am not mistaken Elektra currently treats all plain text key values as strings. I think this is a feature and not a limitation. Elektra is friendly towards existing application configuration schemes. If it
I understand the value and importance of that, but I'm afraid this is out of the Elektra scope. Such semantics and functionality should go in a GConf or KConfig XT layer.
Avi
On 4/2/06, Joe Desbonnet jdesbonnet@gmail.com wrote:
Strings would be a sensible default in the absense of a schema, but I think you could do so much more if you had the *option* to have a schema in the infrastructure.
For each field the schema would define the data type (string, integer, date, ip, username, enum etc), constrains on the values (eg "must be integer between 1-5"), a help text or hyperlink to help, and GUI hints (eg widget preferences: pulldown menu vs radio buttons, tab groupings etc).
So instead of a system-config-blah for each application, you just have one system-config tool that autogenerates a GUI based on schema.
Joe.
On Sun, 2 Apr 2006, Avi Alkalay wrote:
I understand the value and importance of that, but I'm afraid this is out of the Elektra scope. Such semantics and functionality should go in a GConf or KConfig XT layer.
I can see value in a schema library that is optional and elektra aware for non kde/gnome applications. Something that encourages good semantics, but I agree that should be separate.
Cheers, Shane
Has anyone done work on configuration schemas before (eg white paper document or code)? Joe.
On 4/3/06, Shane Stixrud shane@geeklords.org wrote:
I can see value in a schema library that is optional and elektra aware for non kde/gnome applications. Something that encourages good semantics, but I agree that should be separate.
Cheers, Shane
Shane Stixrud <shane <at> geeklords.org> writes:
On Sun, 2 Apr 2006, Avi Alkalay wrote:
I understand the value and importance of that, but I'm afraid this is out of the Elektra scope. Such semantics and functionality should go in a GConf or KConfig XT layer.
I can see value in a schema library that is optional and elektra aware for non kde/gnome applications. Something that encourages good semantics, but I agree that should be separate.
If it is separate, how SHOULD application define variable type (schema)?
Wasn't the purpose of elektra to be able to easily "configure"? With data type information ("schema") written in the registry, it gets much easier (and more inituitive). Yes, you still have everything written as strings, but config programs know automatically how to interpret it.
However it is also important to have available API to set that. I don't think people should use separate library only to have variable type set up, it's ridiculous. API should be extended to support type setting (and maybe variable constrains, etc.) with simplicity in mind, because otherwise most application writers will be likely to omit defining such information (another library just to do that is exactly what shouldn't exist).
Le Dim 2 avril 2006 20:50, Shane Stixrud a écrit :
On Sun, 2 Apr 2006, Nicolas Mailhot wrote:
Again, if you think the problem is on the user side you've already lost it.
That's interesting.... others said the problem was on the user side... and you are saying its on the programmers side...
The problem is on the user side The solution is on the programmers side.
Which is why analysing the problem from the software writer POW (generic API) won't get us anywhere
Now you are just talking double talk.
No. What you absolutely do not want to hear is that system with consistent configuration system APIs are just as bad on the user than Unix configuration files. In fact they are often *worse* because thay make conf file manipulation so transparent for the sotware writer files are cluttered with bad keys and key values.
To the point that the *only* way of recovering apps is locate their conf and zap it.
As for versionning ROTFL the only sane approach to conf file versionning is thinking *long* before adding a key and not changing its name or semantics every other version. You can add as many software versionning tools as you want the simple fact is if your syntax changes every release no one will be able to keep up with you. Even if you have a massive expert system at your disposal.
This is not to say something like elektra wouldn't help a bit, but you're massively overhyping its benefits and underestimating the transition costs. And the fact you're refusing to hear what people tell you does not help you build a solid case.
Who cares if elektra is slightly faster than competitors. Who cares is backup is slightly easier. Hardware is getting faster and faster. Humans are not - and right now given none of the pro-elektra arguments is about making human job easier, my feeling is you're massively micro-optimising the wrong place.
GConf started much the same way as elektra. I didn't notice it making user or admin life easier.
I could be wrong of course. This had been known to happen.
On Mon, 3 Apr 2006, Nicolas Mailhot wrote:
GConf started much the same way as elektra. I didn't notice it making user or admin life easier.
I could be wrong of course. This had been known to happen.
Many features that you apparently take for granted in gnome are ONLY DOABLE due to gconf's unified configuration system. Similar features and functionality for administrators and programmers is non-existent / impractical to create for the remainder of the Linux operation system as it lacks this same functionality. Do you have a technical argument to make on this subject? If not I will kindly refrain from continuing in this discussion with you.
Cheers, Shane
Le Lun 3 avril 2006 10:45, Shane Stixrud a écrit :
On Mon, 3 Apr 2006, Nicolas Mailhot wrote:
GConf started much the same way as elektra. I didn't notice it making user or admin life easier.
I could be wrong of course. This had been known to happen.
Many features that you apparently take for granted in gnome are ONLY DOABLE due to gconf's unified configuration system.
I fear you overstate the technical part (gconf) and understate the social part (an umbrella project getting its members to agree on key namings, values and location)
Similar features and functionality for administrators and programmers is non-existent / impractical to create for the remainder of the Linux operation system as it lacks this same functionality. Do you have a technical argument to make on this subject? If not I will kindly refrain from continuing in this discussion with you.
Java, SOAP, etc. Projects that have focused on the technical plumbing like you, and already have an homogenous technical specification.
Now try to make two java or SOAP apps to talk and you'd better get ready for a boatload of work getting them agree on common semantics (what the REST people have pointed out)
Even if you manage to elektrify Gnome and KDE do you think you'll have more luck getting them agree on common keys than getting them agree on common filesystem objects *now* ?
(oh, right semantics is not your problem, you don't even do typing/schemas but I'm sorry 90% of unix conf woes are semantics only).
Every conf bit is an elektra key. Fine goal. Everything in Unix is a file. Now does it get you much closer to app interoperability?
(oh, right semantics is not your problem, you don't even do typing/schemas but I'm sorry 90% of unix conf woes are semantics only).
I think this is pointing at a key item: apps apply too much semantics on how they read config settings. Maybe common ways could be worked out if bigger projects would cooperate on a common lib/infrastructure for this?
I still agree that this would be a very good goal to aim at, but also know much much work it is to get there. And we already see in this thread on how hard it is to agree on common/acknowledged things. ;-)
regards,
Florian La Roche
P.S.: So while the french are used to bedins and bathrooms without paper, it might take us until development is done by robots to get sane and easy to use config files that support updates. They might also not be needed anymore by that time. ;-)
On Mon, 3 Apr 2006, Florian La Roche wrote:
(oh, right semantics is not your problem, you don't even do typing/schemas but I'm sorry 90% of unix conf woes are semantics only).
I think this is pointing at a key item: apps apply too much semantics on how they read config settings. Maybe common ways could be worked out if bigger projects would cooperate on a common lib/infrastructure for this?
So true. I think the key (pun intended) point the semantic argument is missing is that application configuration semantics by their very nature is easily changed/fixed. So while syntax is a pita to fix due to its functional elements, semantic problems can be identified and patches subjected by novices in many cases. I note that in same cases changing semantics may be more difficult say for example changing dhcpd.conf's subnets directive from using "10.0.0.0 255.255.255.0" to 10.0.0.0-24 but this is the exception not the rule.
I still agree that this would be a very good goal to aim at, but also know much much work it is to get there. And we already see in this thread on how hard it is to agree on common/acknowledged things. ;-)
That I am afraid is an established fact, I do have "faith" that as a community we are capable of moving this in the right direction though... I think the blood bath may be unavoidable however :)
P.S.: So while the french are used to bedins and bathrooms without paper, it might take us until development is done by robots to get sane and easy to use config files that support updates. They might also not be needed anymore by that time. ;-)
Leave it to the french to spoil and otherwise good analogy *sigh*
Cheers, Shane
Florian La Roche laroche@redhat.com wrote:
(oh, right semantics is not your problem, you don't even do typing/schemas but I'm sorry 90% of unix conf woes are semantics only).
I think this is pointing at a key item: apps apply too much semantics on how they read config settings. Maybe common ways could be worked out if bigger projects would cooperate on a common lib/infrastructure for this?
The whole idea of configuration /is/ to provide semantics.
On 4/3/06, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Even if you manage to elektrify Gnome and KDE do you think you'll have more luck getting them agree on common keys than getting them agree on common filesystem objects *now* ?
Yes, this will be the next challenge. But at least will be a social challenge only. Currently nobody talks about any agreenment because the technical plumbing does not allow you to even think about it. Elektra is not the turn key solution. Its impossible to have one in this bazar. It takes time. Elektra at least makes it possible to start thinking about it, but to solve the end problem requires a lot of discussions like this, which is good.
Every conf bit is an elektra key. Fine goal. Everything in Unix is a file. Now does it get you much closer to app interoperability?
It is a step forward in a long walk. And in my opinion its very non-intuitive why converting it in keys makes this walk start. This is normal, and this is why we need a lot of discussions.
Avi
Avi Alkalay avi@unix.sh wrote:
On 4/3/06, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Even if you manage to elektrify Gnome and KDE do you think you'll have more luck getting them agree on common keys than getting them agree on common filesystem objects *now* ?
Yes, this will be the next challenge. But at least will be a social challenge only.
Good luck with that.
Everybody who has had to handle people knows (from bitter experience, mostly) that technical changes are extremely easy to bring about, social changes very hard to impossible. Mostly you have to wait until the older generation has died out, together with its ways of doing things.
Currently nobody talks about any agreenment because the technical plumbing does not allow you to even think about it.
The other way around: If people don't /want/ to talk about it, the existence (or not) of the techical means is utterly irrelevant.
Elektra is not theturn key solution. Its impossible to have one in this bazar. It takes time. Elektra at least makes it possible to start thinking about it, but to solve the end problem requires a lot of discussions like this, which is good.
This flamew^Wdiscussion is going nowhere, it is only wasting everybody's time.
Every conf bit is an elektra key. Fine goal. Everything in Unix is a file. Now does it get you much closer to app interoperability?
It is a step forward in a long walk. And in my opinion its very non-intuitive why converting it in keys makes this walk start. This is normal, and this is why we need a lot of discussions.
If it is, why isn't the "each byte in the configuration file stands for itself" a step forward?
Some (simple) configurations can be described by a bunch of "Variable FOO gets the value BAR", others just cannot (sanely, at least). There is stuff like DNS, a web server for several domains, or the setup of a DHCP server for multiple nets, where you just can't pretend everything is one flat, uniform space. Configuration spaces have structure, and the whole idea of a configuration file with a non-trivial syntax is to be able to mirror said structure. The spaces aren't shaped equal, so either you end up squashing everything into some (unnatural) flat representation or you end up with the sum total of all (possible) diferent shapes (which is completely impossible for a mere human to handle). Sure, you can decree that configuration files are written in XML, which is expressive enough to create its own syntax on a file-by-file basis, but even that doesn't help one bit with the mapping of syntax to semantics (which /is/ the whole point, after all).
On Mon, 3 Apr 2006, Horst von Brand wrote:
Some (simple) configurations can be described by a bunch of "Variable FOO gets the value BAR", others just cannot (sanely, at least). There is stuff like DNS, a web server for several domains, or the setup of a DHCP server for multiple nets, where you just can't pretend everything is one flat, uniform space. Configuration spaces have structure, and the whole idea of a configuration file with a non-trivial syntax is to be able to mirror said structure. The spaces aren't shaped equal, so either you end up squashing everything into some (unnatural) flat representation or you end up with the sum total of all (possible) diferent shapes (which is completely impossible for a mere human to handle). Sure, you can decree that configuration files are written in XML, which is expressive enough to create its own syntax on a file-by-file basis, but even that doesn't help one bit with the mapping of syntax to semantics (which /is/ the whole point, after all).
Have you even read how Elektra works or looked at the earlier multi-subnet dhcpd.conf examples? There is nothing about Elektra that is flat nor does structure have anything to do with semantics! Elektra's format contains all of the functional elements required to EASILY generate dhcpd.conf in its entirety... this has been stated previously...
I am trying to decide if you are purposely being obtuse or just operating on pre-conceived notions... I am trying to give you the benefit of the doubt. IF this thread has low value I dare say it is because of posts like the above that leads to distract and confuse the actual discussion.
Cheers, Shane
Shane Stixrud shane@geeklords.org wrote:
On Mon, 3 Apr 2006, Horst von Brand wrote:
Some (simple) configurations can be described by a bunch of "Variable FOO gets the value BAR", others just cannot (sanely, at least). There is stuff like DNS, a web server for several domains, or the setup of a DHCP server for multiple nets, where you just can't pretend everything is one flat, uniform space. Configuration spaces have structure, and the whole idea of a configuration file with a non-trivial syntax is to be able to mirror said structure. The spaces aren't shaped equal, so either you end up squashing everything into some (unnatural) flat representation or you end up with the sum total of all (possible) diferent shapes (which is completely impossible for a mere human to handle). Sure, you can decree that configuration files are written in XML, which is expressive enough to create its own syntax on a file-by-file basis, but even that doesn't help one bit with the mapping of syntax to semantics (which /is/ the whole point, after all).
Have you even read how Elektra works or looked at the earlier multi-subnet dhcpd.conf examples? There is nothing about Elektra that is flat nor does structure have anything to do with semantics!
There is the central problem: Semantics /is/ structure, can't get rid of the one without losing the other.
Elektra's format contains all of the functional elements required to EASILY generate dhcpd.conf in its entirety... this has been stated previously...
Isn't useful at all unless everybody shares the same configuration variables. And getting everybody to use the same configuration variables is a nightmare...
Having everybody use their own namespace is exactly the mess we are in today, just with the same syntax all over. This is a very minor (if any) step forward; I'd say it is more of a sizeable step backwards.
That there are several backends (plain files, filesystems, gconf, Win registry, ...) just adds a (useless) translation layer that can (and thus will) break when the underlying "real" syntax changes. Plus it goes haywire all the same when some bright mind decides to change the meaning of some configuration construct...
Pray tell, how does adding just another (pretty-printed, I'll grant you) mess to the mix disentangle the whole?
Again, Turing machines have all the elements to construct the kernel in them. Why doesn't somebody do so?
I am trying to decide if you are purposely being obtuse or just operating on pre-conceived notions... I am trying to give you the benefit of the doubt. IF this thread has low value I dare say it is because of posts like the above that leads to distract and confuse the actual discussion.
There is nothing useful to discuss: Elektra is just the Windows registry, done for Unix, /over/ the existing configuration system. It failed miserably there (where they /do/ have the advantage of a rather thight central control point, and no underlying configuration schema that could change under their feet), it can only do much worse here.
On Tue, 2006-03-28 at 14:24 -0800, Shane Stixrud wrote:
On Tue, 28 Mar 2006, Jeff Spaleta wrote:
whether or not elektra is the right solution will be decided by whether or not individual upstream software projects start working towards integrating support for elektra as their default configuration scheme.
This reasoning is flawed and I think it illustrates an example of where our Darwinist Meritocracy has difficultly dealing with problems that are global and counter to our evolutionary path. Tell me, what motivators exist for any project or even groups of projects to adapt a non-standard 3rd parties configuration schema??
Writing configuration files and configuration file parsers is boring, frustrating, error-prone work. If elektra is the right solution we should see new projects embracing it. After that happens, you'll start seeing buyin from the established projects.
How to get more new projects to use it? More language bindings would definitely help....
-Toshio
Writing configuration files and configuration file parsers is boring, frustrating, error-prone work. If elektra is the right solution we should see new projects embracing it. After that happens, you'll start seeing buyin from the established projects.
How to get more new projects to use it? More language bindings would definitely help....
That may be the case, but for some applications say named, dhcp or ldap does it not seem reasonable that a generic configuration format may require a balance between putting less logic in the config structure requiring more of the application? If so I can see how this would be a turn off for some applications even though it may be an overall win for the system as a whole.
Cheers, Shane
On Tue, 2006-03-28 at 14:56 -0800, Shane Stixrud wrote:
Writing configuration files and configuration file parsers is boring, frustrating, error-prone work. If elektra is the right solution we should see new projects embracing it. After that happens, you'll start seeing buyin from the established projects.
How to get more new projects to use it? More language bindings would definitely help....
That may be the case, but for some applications say named, dhcp or ldap does it not seem reasonable that a generic configuration format may require a balance between putting less logic in the config structure requiring more of the application? If so I can see how this would be a turn off for some applications even though it may be an overall win for the system as a whole.
dhcp snippet (dhcp is not on here so hopefully this snippet is valid): default-lease-time 21600; subnet 10.202.46.0 netmask 255.255.255.0 { use-host-decl-names on; option log-servers 10.202.46.2; host ws001 { hardware ethernet 00:11:22:33:44:55; fixed-address 192.168.0.1; default-lease-time 10000 filename "/lts/vmlinuz-2.4.26-ltsp-1"; } }
Here's the same thing in .ini style: [global] default-lease-time 21600
[10.202.46.0] netmask 255.255.255.0 use-host-decl-names on log-servers 10.202.46.2
[ws001] subnet 10.202.46.0 hardware-ethernet 00:11:22:33:44:55 fixed-address 192.168.0.1 default-lease-time 10000 filename "/lts/vmlinuz-2.4.26-ltsp-1"
I'd argue that as the number of subnets and special case workstations goes up, the ability of a system administrator to read and understand the flat file is going to be markedly harder than for the admin to read the custom-crafted dhcp-config syntax.
So if the end-goal is to keep the system-administrator's poor brain from exploding while manually editing the files, I'd say custom-crafted config files can be a win versus the generic one-size-fits-all approach.
-Toshio
On Tue, 28 Mar 2006, Toshio Kuratomi wrote:
dhcp snippet (dhcp is not on here so hopefully this snippet is valid): default-lease-time 21600; subnet 10.202.46.0 netmask 255.255.255.0 { use-host-decl-names on; option log-servers 10.202.46.2; host ws001 { hardware ethernet 00:11:22:33:44:55; fixed-address 192.168.0.1; default-lease-time 10000 filename "/lts/vmlinuz-2.4.26-ltsp-1"; } }
Here's the same thing in .ini style:
[snip]
I'd argue that as the number of subnets and special case workstations goes up, the ability of a system administrator to read and understand the flat file is going to be markedly harder than for the admin to read the custom-crafted dhcp-config syntax.
And I would agree for the .ini format. But things change considerably when instead we deal with all configuration elements as keys and their values in a filesystem like structure. I can now do: "cfg_prog -export .ini/dhcpd/xml/etc.. /system/dhcpd/subnet 10.202.*"
where my default editor may be emacs, vim, gedit or a super config editor.
Shane.
On Wednesday 29 March 2006 00:59, Shane Stixrud wrote:
On Tue, 28 Mar 2006, Toshio Kuratomi wrote:
dhcp snippet (dhcp is not on here so hopefully this snippet is valid): default-lease-time 21600; subnet 10.202.46.0 netmask 255.255.255.0 { use-host-decl-names on; option log-servers 10.202.46.2; host ws001 { hardware ethernet 00:11:22:33:44:55; fixed-address 192.168.0.1; default-lease-time 10000 filename "/lts/vmlinuz-2.4.26-ltsp-1"; } }
Here's the same thing in .ini style:
[snip]
I'd argue that as the number of subnets and special case workstations goes up, the ability of a system administrator to read and understand the flat file is going to be markedly harder than for the admin to read the custom-crafted dhcp-config syntax.
And I would agree for the .ini format.
Really?
How does .ini format give you containers beyond the first level? By numbering the keys? ugh.
The dhcp config file format is a much better match for a) the way people think if they know the problem domain b) allows *hierarchy*. XML at least gets that right (and I *don't* think xml is the answer).
But things change considerably when instead we deal with all configuration elements as keys and their values in a filesystem like structure.
And this is the issue. Look at the mess that is SNMP MIBs. Can you read those? Can you?
I can now do: "cfg_prog -export .ini/dhcpd/xml/etc.. /system/dhcpd/subnet 10.202.*" where my default editor may be emacs, vim, gedit or a super config editor.
Word.
That's the first actual argument I've seen on the opposing side ;)
Shane.
On Wed, 29 Mar 2006, Bill Crawford wrote:
I'd argue that as the number of subnets and special case workstations goes up, the ability of a system administrator to read and understand the flat file is going to be markedly harder than for the admin to read the custom-crafted dhcp-config syntax.
And I would agree for the .ini format.
Really?
How does .ini format give you containers beyond the first level? By numbering the keys? ugh.
The dhcp config file format is a much better match for a) the way people think if they know the problem domain b) allows *hierarchy*. XML at least gets that right (and I *don't* think xml is the answer).
I think you misunderstand. I did not bring up xml or ini files. I was agreeing that a large dhcp config file converted to an .ini file would be a mess.
But things change considerably when instead we deal with all configuration elements as keys and their values in a filesystem like structure.
And this is the issue. Look at the mess that is SNMP MIBs. Can you read those? Can you?
I fail to see the relationship. We are not talking about the windows registry here... in which case the above statement would make sense...
Cheers, Shane
On 3/29/06, Bill Crawford billcrawford1970@gmail.com wrote:
How does .ini format give you containers beyond the first level? By numbering the keys? ugh.
The ini format was a bad example because you get 2 dimensions only. On Elektra you'll have something like this:
default-lease-time 21600; subnet 10.202.46.0 netmask 255.255.255.0 { use-host-decl-names on; option log-servers 10.202.46.2; host ws001 { hardware ethernet 00:11:22:33:44:55; fixed-address 192.168.0.1; default-lease-time 10000 filename "/lts/vmlinuz-2.4.26-ltsp-1"; } }
system/sw/dhcpd/default-lease-time = 21600 system/sw/dhcpd/subnets/10.202.46.0-24/use-host-decl-names = on system/sw/dhcpd/subnets/10.202.46.0-24/options/log-servers = 10.202.46.2 system/sw/dhcpd/subnets/10.202.46.0-24/hosts/ws001/fixed-address = 192.168.0.1 system/sw/dhcpd/subnets/10.202.46.0-24/hosts/ws001/default-lease-time = 10000 system/sw/dhcpd/subnets/10.202.46.0-24/hosts/ws001/filename = /lts/vmlinuz- 2.4.26-ltsp-1 system/sw/dhcpd/subnets/10.202.46.0-24/hosts/ws001/hw = ethernet:00:11:22:33:44:55
The dhcp config file format is a much better match for a) the way people
think if they know the problem domain b) allows *hierarchy*. XML at least gets that right (and I *don't* think xml is the answer).
Anyway, Elektra also provides standard ways for you to represent this hierarchy in an XML format, useful for exporting and importing.
But things change considerably
when instead we deal with all configuration elements as keys and their values in a filesystem like structure.
And this is the issue. Look at the mess that is SNMP MIBs. Can you read those? Can you?
Again, the point is not you (a human being) to read them, but make them accessible in an atomic way to any other (non-human) program.
Avi
On 3/28/06, Toshio Kuratomi toshio@tiki-lounge.com wrote:
If elektra is the right solution we should see new projects embracing it. After that happens, you'll start seeing buyin from the established projects.
How to get more new projects to use it? More language bindings would definitely help....
You know, this is a chicken-and-egg problem. Will be easier to new projects to embrace it if Elektra is automatically present in regular distros, and regular distros will only include Elektra if higher level software starts using it.
Avi
On Thu, 30 Mar 2006 00:47:55 -0300 "Avi Alkalay" avi@unix.sh wrote:
You know, this is a chicken-and-egg problem. Will be easier to new projects to embrace it if Elektra is automatically present in regular distros, and regular distros will only include Elektra if higher level software starts using it.
The Elektra folks should backport some common applications themselves to show developers how easy it is. Say, submitting patches to the upstream Apache project making Elektra a compile time option. Also, getting it in Extras would also help start the ball rolling.
Sean
On Tuesday 28 March 2006 23:24, Shane Stixrud wrote:
This reasoning is flawed and I think it illustrates an example of where our Darwinist Meritocracy has difficultly dealing with problems that are global and counter to our evolutionary path.
It's not flawed reasoning, it's a statement.
There are plenty of reasons why it hasn't happened, among which are a number of experiments with various forms of "registry" ...
The reason most applications use individual config files instead of a central repository is because that makes it much, *much* easier to:
1. Design a domain-specific config language. XML does *NOT* solve this problem; it is a *lexical* (meta)language. The structure goes on top.
2. Point to a different config file when you start a program.
3. Copy config files, rename them, reuse them, move them into chroot() environments, and generally be *free* to do so.
4. There is no step 4.
Tell me, what motivators exist for any project or even groups of projects to adapt a non-standard 3rd parties configuration schema?? None, in fact I am sure there are plenty of reasons NOT to adapt such a thing. When looking at this issue from within a specific microcosms perspective it makes perfect sense why UNIX and Linux have failed to create this standard API after 40+ years of evolution.
So what are you saying?
In fairness I won't attack the straw man. It looks like you are holding one, though.
It is when you look at GNU/LINUX as a whole that this problem becomes obvious and it is for this reason I think Fedora/freedesktop/LSB/FHS or some other entity with ties to the system as a whole will have to champion this standard. A global configuration scheme has little benefit until a large portion of the system is using it, until that threshold is meet it is but another configuration format adding to the systems complexity.
Ah. The "it must all be integrated" straw man. (sigh)
And why are they bothering with SysVinit at all...
My guess is because at the time they did the patches this debate was not hot. It seems they treated sysvinit as a proof of concept that libelektra is usable even at the earliest stages of os initialization.
Why are we all so intent on picking a sysvinit replacement before we have one that's fully useful and does all that the current system does?
On Wed, 29 Mar 2006, Bill Crawford wrote:
There are plenty of reasons why it hasn't happened, among which are a number of experiments with various forms of "registry" ...
Please let's avoid biases centered around an unnamed company implementation. To be simple I am an advocate of ANY on disk, plain text enabled, configuration standard that is designed and modeled after a traditional unix file system.
The reason most applications use individual config files instead of a central repository is because that makes it much, *much* easier to:
- Design a domain-specific config language. XML does *NOT* solve this
problem; it is a *lexical* (meta)language. The structure goes on top.
Point to a different config file when you start a program.
Copy config files, rename them, reuse them, move them into chroot()
environments, and generally be *free* to do so.
I fail to see how any of the above important considerations are limited in any way.
Ah. The "it must all be integrated" straw man. (sigh)
There is no straw man, real advantages and features become available when configuration data is unified.
Shane.
Shane Stixrud shane@geeklords.org wrote:
On Wed, 29 Mar 2006, Bill Crawford wrote:
[...]
Ah. The "it must all be integrated" straw man. (sigh)
There is no straw man, real advantages and features become available when configuration data is unified.
If you mean "single format", I might agree (but that is /much/ harder than it looks, the needs range from a handful of variables to complex structured "programs" in specialized languages). If you also mean "single repository", you are way off the deep end (Hint: Single point of failure, no way to handle alternative configurations, no way to chroot the config, ...)
On Fri, 31 Mar 2006, Horst von Brand wrote:
Shane Stixrud shane@geeklords.org wrote:
On Wed, 29 Mar 2006, Bill Crawford wrote:
[...]
Ah. The "it must all be integrated" straw man. (sigh)
There is no straw man, real advantages and features become available when configuration data is unified.
If you mean "single format", I might agree (but that is /much/ harder than it looks, the needs range from a handful of variables to complex structured "programs" in specialized languages). If you also mean "single repository", you are way off the deep end (Hint: Single point of failure, no way to handle alternative configurations, no way to chroot the config, ...)
By unified I mean all configuration syntax is predictable, hierarchical and standardized.
I also mean multi-repository i.e. Elektra like filesys, dbm etc... My preferred "repository" would be an on-disk hierarchical directory/file structure (filesys) where each application/subsystem has a its own root directory and optional sub-directories.
Read the rest of this thread and you will see all of your concerns have already been addressed i.e. chroot, alternate configs.
Cheers, Shane
On 3/29/06, Bill Crawford billcrawford1970@gmail.com wrote:
There are plenty of reasons why it hasn't happened, among which are a number of experiments with various forms of "registry" ...
It never happend because of the "bazar" nature of the OSS development model. One of its big drawbacks is that there is no central architecture, no central desing directions, no central decisions. So we see A LOT of code rewriting, programs being developed in A LOT of different languages, and A LOT of different configuration files formats.
As we all know, OSS model also have good advantages too.
The reason most applications use individual config files instead of a central repository is because that makes it much, *much* easier to:
- Design a domain-specific config language. XML does *NOT* solve this
problem; it is a *lexical* (meta)language. The structure goes on top.
I see this as a disadvantage, since all, ALL config files are not more then an hierarchical structure of key/value pairs. All lexical stuff you are saying are fat to make it more human readable.
- Point to a different config file when you start a program.
You can also point your program to a different root tree of keys. So using Elektra terminology:
$ httpd -c system/tmp/mytest/mysite.com
- Copy config files, rename them, reuse them, move them into chroot()
environments, and generally be *free* to do so.
You can do the same with configuration trees. Elektra lets you even export some tree to XML, take the file to another machine, and import it into a different root tree. Check http://www.libelektra.org/presentation/img22.html
Avi
On 3/29/06, Bill Crawford billcrawford1970@gmail.com wrote:
There are plenty of reasons why it hasn't happened, among which are a number of experiments with various forms of "registry" ...
It never happend because of the "bazar" nature of the OSS development model. One of its big drawbacks is that there is no central architecture, no central desing directions, no central decisions. So we see A LOT of code rewriting, programs being developed in A LOT of different languages, and A LOT of different configuration files formats.
As we all know, OSS model also have good advantages too.
The reason most applications use individual config files instead of a central repository is because that makes it much, *much* easier to:
- Design a domain-specific config language. XML does *NOT* solve this
problem; it is a *lexical* (meta)language. The structure goes on top.
I see this as a disadvantage, since all, ALL config files are not more then an hierarchical structure of key/value pairs. All lexical stuff you are saying are fat to make it more human readable.
- Point to a different config file when you start a program.
You can also point your program to a different root tree of keys. So using Elektra terminology:
$ httpd -c system/tmp/mytest/mysite.com
- Copy config files, rename them, reuse them, move them into chroot()
environments, and generally be *free* to do so.
You can do the same with configuration trees. Elektra lets you even export
These points are not good enough to deny some sort of standarization.
Avi
On Tue, 2006-03-28 at 13:14 -0800, Shane Stixrud wrote:
On Tue, 28 Mar 2006, Alan Cox wrote:
Gconf doesn't need gnome. The reverse is true however. The XML format also lets you work with prefences using styles and XML XSLT and the like which is very powerful when working with a large number of systems. Really nobody has scratched the surface of what it can do.
http://www.libelektra.org/GConf has a whole list of reasons why they feel gconf would be a bad choice (at least in its current form) for the system configuration api.
If you look through the following, monster thread you'll find that elektra is a bad choice for the desktop configuration api. System and desktop configuration requirements are different. Also, the author of that GConf comparison doesn't seem to understand the problems GConf is attempting to solve which doesn't bode well for it ever displacing GConf.
http://www.redhat.com/archives/fedora-devel-list/2004-July/msg01392.html http://www.redhat.com/archives/fedora-devel-list/2004-August/msg00024.html http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00039.html
-Toshio
On Tue, 28 Mar 2006, Toshio Kuratomi wrote:
If you look through the following, monster thread you'll find that elektra is a bad choice for the desktop configuration api. System and desktop configuration requirements are different. Also, the author of that GConf comparison doesn't seem to understand the problems GConf is attempting to solve which doesn't bode well for it ever displacing GConf.
If I am not mistaken since that time elektra has developed its backends so that they can import/modify/export data from other systems like gconf so that gnome can continue to depend on gconf while users/admins can have a single method of modifying data.
In either case Elektra may very well not be the correct solution, but a technical solution does exist, it may just not of been found/developed yet. There is a problem to be solved here, I haven't heard anyone argue seriously to the contrary and this is by no means a new problem. The purpose of my original post was to start discussion on how that should would look and how we are going to get there in a realistic and reasonable way.
Shane.
On 3/28/06, Shane Stixrud shane@geeklords.org wrote:
In either case Elektra may very well not be the correct solution, but a technical solution does exist, it may just not of been found/developed yet. There is a problem to be solved here, I haven't heard anyone argue seriously to the contrary and this is by no means a new problem. The purpose of my original post was to start discussion on how that should would look and how we are going to get there in a realistic and reasonable way.
By working with upstream project developers and convincing them its worth the effort to solve. What you do not do, if your goal is to actual solve it, is to have this discussion in the scope of a single distributor.
-jef
On Tue, 28 Mar 2006, Jeff Spaleta wrote:
By working with upstream project developers and convincing them its worth the effort to solve. What you do not do, if your goal is to actual solve it, is to have this discussion in the scope of a single distributor.
A serious question for you Jeff, would XML exist in any applications today if it were developed by a few people in some basement and the authors went around trying to convince upstream projects to use it? Let's get real.
Cheers, Shane
Leave aside implementation for the moment... a best practices document (hell, just a Wiki page) on configuration file format would go along way. Just a list of recommendations. Things like how to best handle international characters. A list of common pit falls. A a few config file styles that are considered good, and a few that are examples of how not to do it.
Joe.
On 3/28/06, Shane Stixrud shane@geeklords.org wrote:
On Tue, 28 Mar 2006, Jeff Spaleta wrote:
By working with upstream project developers and convincing them its worth the effort to solve. What you do not do, if your goal is to actual solve it, is to have this discussion in the scope of a single distributor.
A serious question for you Jeff, would XML exist in any applications today if it were developed by a few people in some basement and the authors went around trying to convince upstream projects to use it? Let's get real.
Cheers, Shane
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On 3/28/06, Joe Desbonnet jdesbonnet@gmail.com wrote:
Leave aside implementation for the moment... a best practices document (hell, just a Wiki page) on configuration file format would go along way. Just a list of recommendations. Things like how to best handle international characters. A list of common pit falls. A a few config file styles that are considered good, and a few that are examples of how not to do it.
Again this is not a discussion that should be happening inside the scope of fedora.
Hint: google for configuration specification discussions that have occured already in distribution and application neutral forums. Hint 2: freedesktop and related mailinglists Hint 3: D-Conf
-jef
On Tuesday 28 March 2006 23:52, Joe Desbonnet wrote:
Things like how to best handle international characters.
utf-8
A list of common pit falls.
Trying to create a "one size fits all" configuration language for all applications.
Trying to shoehorn a popular data-encoding method (xml) into all niches you can think of.
A a few config file styles that are considered good, and a few that are examples of how not to do it.
Good: Exim; dhcp; xinetd (as opposed to original inetd although the basic ideas are similar, the directory structure allowing split files is a big improvement over the single .conf file).
Bad: almost anything using .ini ;) *please note the ALMOST* if the data set basically only has one or two dimensions, .ini will work fine. It will limit you in the future, maybe.
Le mercredi 29 mars 2006 à 04:44 +0100, Bill Crawford a écrit :
A list of common pit falls.
Pitfall #1 : creating the perfect general serialization API so developers can save whatever data they feel like to without thinking 5s how other people will interact with it. This is what I call software-oriented junk
Pitfall #2 : creating handcrafted file format no standard tools can interact sanely with. This is human-oriented junk
People tend to dismiss XML because a lot of its proponents have fallen in pitfall #1. Usually they jump in pitfall #2 as a result.
A popular way to combine pitfall #1 and #2 is to create configuration tools which use a private data backend with pitfall #1, and convert it at save time in the actual handcrafted app conf file with pitfall #2.
Good projects start by choosing general syntax rules that make software happy (usually XML) then fine-tune them with humans in mind (what if the whole file had to be written by a human in a text editor and you had to write the associated manual) See for example fontconfig, apache ant syntax, etc
On Wed, 2006-03-29 at 04:44 +0100, Bill Crawford wrote:
Good: Exim; dhcp; xinetd (as opposed to original inetd although the basic ideas are similar, the directory structure allowing split files is a big improvement over the single .conf file).
Apache, squid, Xorg, gdm.
Bad: almost anything using .ini ;) *please note the ALMOST* if the data set basically only has one or two dimensions, .ini will work fine. It will limit you in the future, maybe.
fontconfig. Bind. Sendmail.
On Sun, 2 Apr 2006, Callum Lerwick wrote:
On Wed, 2006-03-29 at 04:44 +0100, Bill Crawford wrote:
Good: Exim; dhcp; xinetd (as opposed to original inetd although the basic ideas are similar, the directory structure allowing split files is a big improvement over the single .conf file).
Apache, squid, Xorg, gdm.
Interesting. Tell me what is the best way to enable XDMCP in gdm via a configuration script? I'll give ya a hint Enable=false is often defined in multiple places within gdm.conf and the line numbers for these statements have and will change.
Configuration files that require either a) manual editing or b) complex error prone scripting are _NOT_ "Good".
Cheers, Shane
On Sun, 2006-04-02 at 01:37 -0800, Shane Stixrud wrote:
Interesting. Tell me what is the best way to enable XDMCP in gdm via a configuration script? I'll give ya a hint Enable=false is often defined in multiple places within gdm.conf and the line numbers for these statements have and will change.
For FC5 gdm, plop down a gdm.conf-custom with whatever settings you need in it. Bam, you're done.
Yes, previous versions of gdm were brain damaged in this regard. Its better now.
On 4/2/06, Callum Lerwick seg@haxxed.com wrote:
On Sun, 2006-04-02 at 01:37 -0800, Shane Stixrud wrote:
Interesting. Tell me what is the best way to enable XDMCP in gdm via a configuration script? I'll give ya a hint Enable=false is often defined in multiple places within gdm.conf and the line numbers for these statements have and will change.
For FC5 gdm, plop down a gdm.conf-custom with whatever settings you need in it. Bam, you're done.
Yes, previous versions of gdm were brain damaged in this regard. Its better now.
Really!? Oh thank you! I didn't know it was so simple! Ok, lets shutdown this whole Elektra Iniative after you give us same simple solution for Shane's simple requirement for script-handling these configurations:
/etc/named.conf, /etc/dhcpd.conf, /etc/X11/xorg.conf, /etc/wvdial.conf, /etc/wgetrc, /etc/hosts.[conf|allow|deny], /etc/nsswitch.conf, /etc/ldap.conf, /etc/lisarc, /etc/samba/*.conf /etc/ntp.conf /etc/xinetd.conf /etc/xinetd.d/* /etc/modprobe.conf /etc/prelink.conf /etc/resolv.conf /etc/sysconfig/* /etc/sysconfig/network-scripts/ifcfg-* /etc/issue* /etc/yum.conf /etc/pam.d/* /etc/openldap/ldap.conf /etc/enscript.cfg /etc/fstab /etc/filesystems /etc/{any new thing that may appear}
Remember: your solution must be homogeneous, like, people are not interested in hundred different solution for each of these hundreds files. Oh, and please provide a solutions that is distribution agnostic (remember that these files can be located in other places in other distros).
I'm desperately just waiting for your e-mail.
Thank you, Avi
On Sun, 2006-04-02 at 10:41 -0300, Avi Alkalay wrote:
Really!? Oh thank you! I didn't know it was so simple! Ok, lets shutdown this whole Elektra Iniative after you give us same simple solution for Shane's simple requirement for script-handling these configurations:
[long list cut]
Remember: your solution must be homogeneous, like, people are not interested in hundred different solution for each of these hundreds files. Oh, and please provide a solutions that is distribution agnostic (remember that these files can be located in other places in other distros).
I'm desperately just waiting for your e-mail.
Thank you, Avi
No, thank you. Now we're getting somewhere.
Le dimanche 02 avril 2006 à 01:37 -0800, Shane Stixrud a écrit :
On Sun, 2 Apr 2006, Callum Lerwick wrote:
On Wed, 2006-03-29 at 04:44 +0100, Bill Crawford wrote:
Good: Exim; dhcp; xinetd (as opposed to original inetd although the basic ideas are similar, the directory structure allowing split files is a big improvement over the single .conf file).
Apache, squid, Xorg, gdm.
Interesting. Tell me what is the best way to enable XDMCP in gdm via a configuration script? I'll give ya a hint Enable=false is often defined in multiple places within gdm.conf and the line numbers for these statements have and will change.
Configuration files that require either a) manual editing or b) complex error prone scripting are _NOT_ "Good".
But why is the gdm conf file such crap ? Is this because gdm writers had not lots of advanced configuration file libs at their disposition ?
No
It's because they consider : 1. the conf file is none of the user business 2. as a result little thought went in key naming 3. and even worse the keys themselves are not stable from release to release
How is elektra going to help with this ?
On Sun, 2 Apr 2006, Nicolas Mailhot wrote:
But why is the gdm conf file such crap ? Is this because gdm writers had not lots of advanced configuration file libs at their disposition ?
No
It's because they consider :
- the conf file is none of the user business
- as a result little thought went in key naming
- and even worse the keys themselves are not stable from release to
release
How is elektra going to help with this ?
It should be obvious having read http://www.libelektra.org. Anyways with a hierarchical key/value system like Elektra the solution is simple.
echo "true" >/$CONFIGDIR/system/sw/gdm/xdmcp/enable
Cheers, Shane
Le dimanche 02 avril 2006 à 04:04 -0700, Shane Stixrud a écrit :
On Sun, 2 Apr 2006, Nicolas Mailhot wrote:
But why is the gdm conf file such crap ? Is this because gdm writers had not lots of advanced configuration file libs at their disposition ?
No
It's because they consider :
- the conf file is none of the user business
- as a result little thought went in key naming
- and even worse the keys themselves are not stable from release to
release
How is elektra going to help with this ?
It should be obvious having read http://www.libelektra.org. Anyways with a hierarchical key/value system like Elektra the solution is simple.
bzzt. hierarchical was already available when gconf was written (either by using XML of java-like hierarchical properties)
That is was not used is not a conf lib problem
On Sun, 2 Apr 2006, Nicolas Mailhot wrote:
Le dimanche 02 avril 2006 à 04:04 -0700, Shane Stixrud a écrit :
It should be obvious having read http://www.libelektra.org. Anyways with a hierarchical key/value system like Elektra the solution is simple.
bzzt. hierarchical was already available when gconf was written (either by using XML of java-like hierarchical properties)
That is was not used is not a conf lib problem
This ground as already been covered, gconf was not designed with the whole system in mind. XML has its own complexity especially if we want to be able to use UNIX applications to easily edit them.
I am not interested in debating. I am interested in working on solutions.
On Sun, 2 Apr 2006, Shane Stixrud wrote:
On Sun, 2 Apr 2006, Nicolas Mailhot wrote:
But why is the gdm conf file such crap ? Is this because gdm writers had not lots of advanced configuration file libs at their disposition ?
No
Yes, arbitrary key names and value types do not limit the programmability or user intractability in _ANY_ way what so ever. Poor key names and values are SUBJECTIVE and thus can only be judged good or bad by their tendency to cause understanding or confusion.
It's because they consider :
- the conf file is none of the user business
- as a result little thought went in key naming
- and even worse the keys themselves are not stable from release to
release
No, it is because naming is subjective in nature and what seems like a good name to an author might not be statistically a good choice for the masses. Btw the same holds true for configuration syntax and it is for this reason that a simple syntax that maintains all of the depth and functionality is superior to a complex custom syntax.
Cheers, Shane
On 3/28/06, Shane Stixrud shane@geeklords.org wrote:
A serious question for you Jeff, would XML exist in any applications today if it were developed by a few people in some basement and the authors went around trying to convince upstream projects to use it? Let's get real.
I said i was giving Elektra the benefit of the doubt. It could very well be that their implementation is in fact not a useful implementation and its not a compelling thing to use by either new projects nor established projects... but I was trying to be nice. Being nice is not my strong suit and everytime I attempt to be nice miscommunication happens. Sorry about that. Let me try a style of communication that I'm more comfortable with using the subtle nuances of.
The discussion of this issue on the fedora lists is a waste of everyone's time. Discussion of how to solve similar problems have already happened in the context of freedesktop. If you spent a little more time doing research instead of blowing hot air into this list you would have discovered the D-Conf spec and related discussion and followed up on it to see how its impacting upstream GConf development. All of which happens outside the scope of fedora.
-jef
On Tue, 28 Mar 2006, Jeff Spaleta wrote:
would have discovered the D-Conf spec and related discussion and followed up on it to see how its impacting upstream GConf development. All of which happens outside the scope of fedora.
"D-Conf generated a long discussion on FreeDesktop.org's XDG mailling list. Its objective is to standarize configuration across desktop frameworks like Gnome and KDE, so no focus is being devoted to global non-desktop system configurations.
It was very difficult to find the D-Conf website (not found in the end), and seems that all is available is that XDG discussion, and a wiki page containing analisys of what is required, and development directions. Nothing else.
Conclusion: D-Conf is vaporware. "
source: http://www.libelektra.org/D-Conf
I hope you are right and D-conf is making a difference, that seems to be debatable however. Btw by all means do not be nice on my account, I enjoy raw personality :).
Cheers, Shane
In addition to the words bellow, the "D" on D-Conf comes from the "Desktop" word, which means D-Conf is a desktop-oriented wannabe-project. You won´t be able to standarize configuration for say named, dhcpd, resolver, sysctl, modprobe, /sbin/init, network configurations, etc etc etc with it.
On 3/28/06, Shane Stixrud shane@geeklords.org wrote:
On Tue, 28 Mar 2006, Jeff Spaleta wrote:
would have discovered the D-Conf spec and related discussion and followed up on it to see how its impacting upstream GConf development. All of which happens outside the scope of fedora.
"D-Conf generated a long discussion on FreeDesktop.org's XDG mailling list. Its objective is to standarize configuration across desktop frameworks like Gnome and KDE, so no focus is being devoted to global non-desktop system configurations.
It was very difficult to find the D-Conf website (not found in the end), and seems that all is available is that XDG discussion, and a wiki page containing analisys of what is required, and development directions. Nothing else.
Conclusion: D-Conf is vaporware. "
source: http://www.libelektra.org/D-Conf
I hope you are right and D-conf is making a difference, that seems to be debatable however. Btw by all means do not be nice on my account, I enjoy raw personality :).
Cheers, Shane
On Mar 29, 2006, at 7:29 PM, Avi Alkalay wrote:
In addition to the words bellow, the "D" on D-Conf comes from the "Desktop" word, which means D-Conf is a desktop-oriented wannabe- project. You won´t be able to standarize configuration for say named, dhcpd, resolver, sysctl, modprobe, /sbin/init, network configurations, etc etc etc with it.
Speaking of wanna-be. I think one fundamental problem with the LinuxRegistry/Elektra approach is that you try to fix the symptoms of the problem instead of the root problems. I've written about this before and I will do it again and again as apparently people are still trying to fix the symptoms of our problem:
Configuration of software in a mainstream distribution is a mess.
Most of this mail is about the desktop, but really, if you look at it, desktop is _a lot harder_ than server (there is just so much more code and so much more functionality) so my view is that if we solve it for desktop then the server bits will pan out mostly by itself.
It seems that Elektra simply wants to remap the configuration file for a piece "software" into a hierarchical key/value database and I think that's missing the point entirely. First of all you got to ask yourself whether there should be a configuration of said piece of software in the first place. If you think really hard about it you will find that for most pieces of software this is false - you really don't want any configuration files... Hence you really don't want nor need Elektra.
Let us look at what "configuration" really means; I've seen it being used in the following ways
- The programmer is lazy and makes the user look up configuration values he could have determined programmatically - for example this includes the laptop_mode scripts where you can configure what IDE drives to put to sleep. The poor user will have to put in arcane values such as "/dev/hda", "/dev/hdd" and so forth. You know, maybe the laptop_mode developer wasn't that lazy, maybe the kernel people was just sleeping and gave him no easy way to find out what drives to put to sleep when he wants.. or maybe what the kernel said was unreliable and the kernel never got fixed.... Does this justify bothering the poor end user with crap like this? I think not.
- Configuration can be system-wide, for example mail and web servers... Sure, my web server needs to know where to serve files from, my mail server needs to know what domain it serves and so forth
- When developers write a daemon and decide to make it system-wide, then most of the time they either really want it to be site-wide or session-wide instead. Most of the time they don't even know this... I will argue that system-wide is just plain wrong for most things; continue reading...
- Site-wide software: This includes for example a cluster of web servers. The user experience if I'm an administrator is that I can just plug in another physical server box, PXE-boot it and it reads all "web server configuration" from LDAP. If it blows up I can replace it. Hence, no need at all for having some httpd.conf file. For the (terribly uninteresting) case of only having one machine as a web server it reads settings from the local LDAP server. Ditto with mail servers, name servers etc.
- Session-wide software: Just so we're all on the same page, "session-wide" means something that runs in a user desktop session. Historically, the desktop wasn't very advanced and didn't integrate well with the system. Back then things that really was session-wide would run as a system-wide daemon mostly also because it required root to enforce policy. Things like acpid for power management event handling, updfstab for removable media, ifplugd for handling network cable removable, networking scripts etc. comes to mind. As you can see with Fedora Core 5 this is radically starting to change; acpid is obsoleted by gnome-power-manager, updfstab (and fstab-sync for that matter) is obsoleted by gnome-volume-manager / gnome-mount, the networking scripts is starting to be completely obsoleted by NetworkManager. We have more things on out "hit list"...
- You really really want session-wide daemons to run in the session and not as the system because it's much easier for the user to configure it.. in fact, you get per-user settings for removable media handling and power management in FC5. And since all this is backed by gconf it's easy for the OS vendor _and_ the administrator to set sane defaults, lock things down and so forth. It's just a lot better
- Look at the terrible and insecure hacks for writing out configuration files for system-wide daemons that ought to be session- wide. See also my rant on fedora-maintainers last week why consolehelper (that these tools rely on) is fundamentally flawed.
- Things like smb.conf is really not interesting for the desktop case as it's the wrong solution to the problem of sharing files and using files other systems wants to share. The right answer here is obviously things like Nautilus and gnome-user-share and other things that run in your session and is easy to configure.
- X.org having a configuration is completely broken too; obviously the X.org server should be able to configure itself (and it can but X.org itself has bugs so it doesn't always work) and it should offer a D-BUS interface for reconfiguration so some per-session piece of software can program it with the users setting when your session starts. Yes, display configuration is also per-user although the brain dead design of X.org doesn't reflect this.
I don't have a good answer to KDE and GNOME sharing configuration; I personally think that as this point it's impossible to get developers of both camp to agree on a scheme for even simple things like desktop backgrounds and HTTP proxies. And should the day come when gconf depends on KConfig, vice versa, or when there is D-Conf I'm sure this will get solved by itself. It sure as hell doesn't need Elektra for this.
So my message is that I think it's a waste of time trying to shoehorn a configuration file format onto all kinds of software because said software is likely to be already broken for at least desktop use. My stance is simply that it's unacceptable in a desktop system to ever ever have to touch a configuration file and I think some people (*cough* Apple *cough* Microsoft *cough*) take the same stance even for the server. So we shouldn't ship software that rely on them. Hence, there is zero need for Elektra. It's really that simple if you think about it.
I wish that people working on the server bits (e.g. Apache, Postfix) would take a similar stance and only make their software read settings from LDAP (or whatever) for the site-wide case. I think it would be great if you could change Elektra into something that would fix this. But please back off trying to pretend you solve problems for the desktop because you're not. The design of gconf is pretty nice (implementation might be another matter but, you know, that's totally fixable) and it's more than sufficient for desktop use, thank you very much.
Hope this clarifies why Elektra is simply the wrong answer. I'm sorry for sounding harsh and saying most of our software in the distribution is broken, but it's kinda this conclusion I've arrived at. We could do so much better if we all tried to solve the root problems and look at what the user experience should be.
Have a nice day.
David
Disclaimer : this mail doesn't necessarily reflect the views of Red Hat, Inc.
On Mon, 2006-04-03 at 01:27 -0400, David Zeuthen wrote:
- Session-wide software: Just so we're all on the same page,
"session-wide" means something that runs in a user desktop session. Historically, the desktop wasn't very advanced and didn't integrate well with the system. Back then things that really was session-wide would run as a system-wide daemon mostly also because it required root to enforce policy. Things like acpid for power management event handling, updfstab for removable media, ifplugd for handling network cable removable, networking scripts etc. comes to mind. As you can see with Fedora Core 5 this is radically starting to change; acpid is obsoleted by gnome-power-manager, updfstab (and fstab-sync for that matter) is obsoleted by gnome-volume-manager / gnome-mount, the networking scripts is starting to be completely obsoleted by NetworkManager. We have more things on out "hit list"...
Are these grand plans written down somewhere? Any pointers? It would be good to let the rest of us know what is happening in advance. For example. fstab-sync being replaced gnome-mount might have been good in the longer term but the policy was changed to not show fixed disks by default (http://fedoraproject.org/wiki/Docs/Beats/PackageNotes). We didn't know about this and we only included this information after the ISO freeze for the release notes. Now that information has been to be pushed out as an errata and meanwhile it has been a FAQ and confused many end users. It would have been good to send the docs team a short note with rationale. Writing down publicly the development plans is just The Right Thing To Do(TM).
Rahul
On Mon, 3 Apr 2006, David Zeuthen wrote:
It seems that Elektra simply wants to remap the configuration file for a piece "software" into a hierarchical key/value database and I think that's missing the point entirely. First of all you got to ask yourself whether there should be a configuration of said piece of software in the first place. If you think really hard about it you will find that for most pieces of software this is false - you really don't want any configuration files... Hence you really don't want nor need Elektra.
Software without configuration options what a novel idea... In all seriousness that day will come long after the paperless bathroom....
Cheers, Shane
On Apr 3, 2006, at 2:17 AM, Shane Stixrud wrote:
On Mon, 3 Apr 2006, David Zeuthen wrote:
It seems that Elektra simply wants to remap the configuration file for a piece "software" into a hierarchical key/value database and I think that's missing the point entirely. First of all you got to ask yourself whether there should be a configuration of said piece of software in the first place. If you think really hard about it you will find that for most pieces of software this is false - you really don't want any configuration files... Hence you really don't want nor need Elektra.
Software without configuration options what a novel idea... In all seriousness that day will come long after the paperless bathroom....
My point was that you don't want _configuration files_, of course you need configuration for some, even most, pieces of software. Another point was that this configuration should be read from either the desktop session _or_ some remote LDAP server. Maybe if you read my whole mail before replying this would have been clear.
David
On Sun, 2006-04-02 at 23:17 -0700, Shane Stixrud wrote:
On Mon, 3 Apr 2006, David Zeuthen wrote:
It seems that Elektra simply wants to remap the configuration file for a piece "software" into a hierarchical key/value database and I think that's missing the point entirely. First of all you got to ask yourself whether there should be a configuration of said piece of software in the first place. If you think really hard about it you will find that for most pieces of software this is false - you really don't want any configuration files... Hence you really don't want nor need Elektra.
Software without configuration options what a novel idea... In all seriousness that day will come long after the paperless bathroom....
Well paperless bathrooms with a bidet has been around for over 300 years now.
Christian
On Mon, 3 Apr 2006, Christian Fredrik Kalager Schaller wrote:
Software without configuration options what a novel idea... In all seriousness that day will come long after the paperless bathroom....
Well paperless bathrooms with a bidet has been around for over 300 years now.
Lol, well then self configuration strong AI desktop applications must be right around the corner then ;)
Cheers, Shane
On Mon, Apr 03, 2006 at 10:14:18AM +0200, Christian Fredrik Kalager Schaller wrote:
Well paperless bathrooms with a bidet has been around for over 300 years now.
And with a jug for rather longer...
David Zeuthen david@fubar.dk wrote:
On Mar 29, 2006, at 7:29 PM, Avi Alkalay wrote:
In addition to the words bellow, the "D" on D-Conf comes from the "Desktop" word, which means D-Conf is a desktop-oriented wannabe- project. You won´t be able to standarize configuration for say named, dhcpd, resolver, sysctl, modprobe, /sbin/init, network configurations, etc etc etc with it.
Speaking of wanna-be. I think one fundamental problem with the LinuxRegistry/Elektra approach is that you try to fix the symptoms of the problem instead of the root problems. I've written about this before and I will do it again and again as apparently people are still trying to fix the symptoms of our problem:
Configuration of software in a mainstream distribution is a mess.
Most of this mail is about the desktop, but really, if you look at it, desktop is _a lot harder_ than server (there is just so much more code and so much more functionality) so my view is that if we solve it for desktop then the server bits will pan out mostly by itself.
No, the problem spaces are different.
It seems that Elektra simply wants to remap the configuration file for a piece "software" into a hierarchical key/value database and I think that's missing the point entirely. First of all you got to ask yourself whether there should be a configuration of said piece of software in the first place. If you think really hard about it you will find that for most pieces of software this is false - you really don't want any configuration files... Hence you really don't want nor need Elektra.
;-)
Let us look at what "configuration" really means; I've seen it being used in the following ways
- The programmer is lazy and makes the user look up configuration
values he could have determined programmatically - for example this includes the laptop_mode scripts where you can configure what IDE drives to put to sleep. The poor user will have to put in arcane values such as "/dev/hda", "/dev/hdd" and so forth. You know, maybe the laptop_mode developer wasn't that lazy, maybe the kernel people was just sleeping and gave him no easy way to find out what drives to put to sleep when he wants.. or maybe what the kernel said was unreliable and the kernel never got fixed.... Does this justify bothering the poor end user with crap like this? I think not.
I don't know about this specific case, but if so, I heartily agree.
- Configuration can be system-wide, for example mail and web
servers... Sure, my web server needs to know where to serve files from, my mail server needs to know what domain it serves and so forth
Bingo! I.e., configuration /is/ needed...
- When developers write a daemon and decide to make it system-wide,
then most of the time they either really want it to be site-wide or session-wide instead. Most of the time they don't even know this... I will argue that system-wide is just plain wrong for most things; continue reading...
- Site-wide software: This includes for example a cluster of web
servers. The user experience if I'm an administrator is that I can just plug in another physical server box, PXE-boot it and it reads all "web server configuration" from LDAP. If it blows up I can replace it. Hence, no need at all for having some httpd.conf file. For the (terribly uninteresting) case of only having one machine as a web server it reads settings from the local LDAP server. Ditto with mail servers, name servers etc.
So you advocate not configuring the web server via files, but remotely via LDAP? How is that different from "configuration files"?
In any case, this is system-wide, just that your system is larger than one box.
- Session-wide software: Just so we're all on the same page,
"session-wide" means something that runs in a user desktop session. Historically, the desktop wasn't very advanced and didn't integrate well with the system. Back then things that really was session-wide would run as a system-wide daemon mostly also because it required root to enforce policy. Things like acpid for power management event handling, updfstab for removable media, ifplugd for handling network cable removable, networking scripts etc. comes to mind. As you can see with Fedora Core 5 this is radically starting to change; acpid is obsoleted by gnome-power-manager, updfstab (and fstab-sync for that matter) is obsoleted by gnome-volume-manager / gnome-mount, the networking scripts is starting to be completely obsoleted by NetworkManager. We have more things on out "hit list"...
Great. But that does mean that someone, somewhere has to tweak the configuration (files) with all those desktop settings that the machine gets over the net. Plus I'd bet the number of single-machine setups vastly outnumber the multi-client setting you describe, and will for a long time to come. By pushing the problem into the site-wide system administrations hands you have solved nothing.
- You really really want session-wide daemons to run in the session
and not as the system because it's much easier for the user to configure it.. in fact, you get per-user settings for removable media handling and power management in FC5. And since all this is backed by gconf it's easy for the OS vendor _and_ the administrator to set sane defaults, lock things down and so forth. It's just a lot better
That is, as long as gconf is used...
- Look at the terrible and insecure hacks for writing out
configuration files for system-wide daemons that ought to be session- wide.
That some people don't know how to do it right doesn't mean it is the wrong approach.
See also my rant on fedora-maintainers last week whyconsolehelper (that these tools rely on) is fundamentally flawed.
- Things like smb.conf is really not interesting for the desktop
case as it's the wrong solution to the problem of sharing files and using files other systems wants to share. The right answer here is obviously things like Nautilus and gnome-user-share and other things that run in your session and is easy to configure.
Destop has no business in deciding what system-wide resources to share.
- X.org having a configuration is completely broken too; obviously
the X.org server should be able to configure itself (and it can but X.org itself has bugs so it doesn't always work) and it should offer a D-BUS interface for reconfiguration so some per-session piece of software can program it with the users setting when your session starts.
Pray tell, where would the user settings come from? Not from a configuration file?!
Yes, display configuration is also per-user although thebrain dead design of X.org doesn't reflect this.
I'm not so sure. The display is a system resource.
I don't have a good answer to KDE and GNOME sharing configuration; I personally think that as this point it's impossible to get developers of both camp to agree on a scheme for even simple things like desktop backgrounds and HTTP proxies. And should the day come when gconf depends on KConfig, vice versa, or when there is D-Conf I'm sure this will get solved by itself. It sure as hell doesn't need Elektra for this.
That is the crux of the matter: Glorious schemes for world domination "if only everybody will agree on the same configuration file syntax" are thrown around here, but the ones in charge of adopting said syntax have historically shown very, very little desire to agree on a syntax. And (assuming people aren't completely irrational), the very existence of the wildly differing syntaxes tells me there are different needs behind them.
So my message is that I think it's a waste of time trying to shoehorn a configuration file format onto all kinds of software because said software is likely to be already broken for at least desktop use. My stance is simply that it's unacceptable in a desktop system to ever ever have to touch a configuration file and I think some people (*cough* Apple *cough* Microsoft *cough*) take the same stance even for the server. So we shouldn't ship software that rely on them. Hence, there is zero need for Elektra. It's really that simple if you think about it.
I wish that people working on the server bits (e.g. Apache, Postfix) would take a similar stance and only make their software read settings from LDAP (or whatever) for the site-wide case. I think it would be great if you could change Elektra into something that would fix this. But please back off trying to pretend you solve problems for the desktop because you're not. The design of gconf is pretty nice (implementation might be another matter but, you know, that's totally fixable) and it's more than sufficient for desktop use, thank you very much.
So your idea is getting rid of configuration files and push everything into LDAP? What if the LDAP server is down?
Who says LDAP is the right framework, i.e., is rich enough for the needs? Who says the result won't be just shoveling the garbage into another opaque junkyard?
On 4/3/06, Horst von Brand vonbrand@inf.utfsm.cl wrote:
That is the crux of the matter: Glorious schemes for world domination "if only everybody will agree on the same configuration file syntax" are thrown around here, but the ones in charge of adopting said syntax have historically shown very, very little desire to agree on a syntax.
Here comes the role of distributions as the integrator. This is why I say each of these projects (Apache, Samba, everything on /etc/*, Gnome, KDE, etc) are a sort of "selfish" and "proprietary" when it comes to overall integration architecture.
So your idea is getting rid of configuration files and push everything into LDAP? What if the LDAP server is down?
What if you don't have/want a network? What if my mother only wants to install a new multimedia keyboard in her standalone Linux box? She'll have to edit /etc/X11/xorg.conf? Or wait for the distribution's HW detection tool to know how to handle that? Clearly the best solutions is to let the HW provider know that X.org configurations are pretty predictable in any distribution, and it just have to provide some scripts to precisely integrate itself in X.org configuration schema, instead of having to "compile", understand and regenerate /etc/X11/xorg.conf only to install itself. Being so difficult, this HW provider will simply, obviously, declare they do not support Linux.
Avi
Le Lun 3 avril 2006 17:11, Avi Alkalay a écrit :
What if my mother only wants to install a new multimedia keyboard in her standalone Linux box? She'll have to edit /etc/X11/xorg.conf? Or wait for the distribution's HW detection tool to know how to handle that? Clearly the best solutions is to let the HW provider know that X.org configurations are pretty predictable in any distribution, and it just have to provide some scripts to precisely integrate itself in X.org configuration schema, instead of having to "compile", understand and regenerate /etc/X11/xorg.conf only to install itself.
Avi,
I agree with much of what you've written lately but here you're back in lala-lala land.
You can't have several entities sharing the same object (here entities are xorg and your mythical keyboard manufacturer). It *always* ends bad because the first reflex of the keyboard manufacturer will be to "canonalize" the conf to something it tested (and testing is expensive so don't count on a complex canonic setup), lower various tuneables to workaround its product bugs, and generally destroy the settings the mythical mouse manufacturer put in the configuration.
Having central clearinghouses that mediate between actors (LKML, xorg, distributions) is a very powerful feature of Linux distributions (you'll note ms has been increasingly centralising driver handling in the last years for this very same reason). Your manufacturer should push its changes upstream instead of expending resources trying to workaround the system.
In other words, your "fix" is worse than the "problem".
Regards,
On Mon, 3 Apr 2006, Nicolas Mailhot wrote:
You can't have several entities sharing the same object (here entities are xorg and your mythical keyboard manufacturer). It *always* ends bad
.... and why is that? If an application is designed to allow an end user to update something then why not a vendor on the users behalf??
Microsoft got MANY things wrong, but I dare say keyboard vendors and their users have little to worry about on this front. Please give TECHNICAL reasons why this functionality is a bad idea, so far you have relied on subjective conjecture centered around how you THINK others will behave. It is not your or my place to limit functionality based on our opinions on if it will be used poorly or not. The fact is all of this cane be done today it is just very hard to do, this argument that making it easier for the user, programmer and vendor will some how create a social disaster rings hollow to me.
Cheers, Shane
Nicolas, is very hard to discuss opinions and that was your opinion. I respect that, even if I can't understand in what you based this opinion.
In my opinion, if you provide an environment where softwares can cooperate in the configuration layer (which is software's personality) and define some standards and policies for chaos minimization (which is reflected by this driver handling centralization from your example; we are not talking only about HW drivers), the ecosystem of integrated applications and ways to work will increase everyday, leveraging richer user experience and friendliness. You may have even tools that help you clean the chaos. My opinion is based mostly in observable evidence on what happened in the Windows world (the good parts), and a bit of intuition.
Thank you, Avi
On 4/3/06, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le Lun 3 avril 2006 17:11, Avi Alkalay a écrit :
What if my mother only wants to install a new multimedia keyboard in her standalone Linux box? She'll have to edit /etc/X11/xorg.conf? Or wait for the distribution's HW detection tool to know how to handle that? Clearly the best solutions is to let the HW provider know that X.org configurations are pretty predictable in any distribution, and it just have to provide some scripts to precisely integrate itself in X.org configuration schema, instead of having to "compile", understand and regenerate /etc/X11/xorg.conf only to install itself.
Avi,
I agree with much of what you've written lately but here you're back in lala-lala land.
You can't have several entities sharing the same object (here entities are xorg and your mythical keyboard manufacturer). It *always* ends bad because the first reflex of the keyboard manufacturer will be to "canonalize" the conf to something it tested (and testing is expensive so don't count on a complex canonic setup), lower various tuneables to workaround its product bugs, and generally destroy the settings the mythical mouse manufacturer put in the configuration.
Having central clearinghouses that mediate between actors (LKML, xorg, distributions) is a very powerful feature of Linux distributions (you'll note ms has been increasingly centralising driver handling in the last years for this very same reason). Your manufacturer should push its changes upstream instead of expending resources trying to workaround the system.
In other words, your "fix" is worse than the "problem".
Regards,
-- Nicolas Mailho
Le lundi 03 avril 2006 à 14:51 -0300, Avi Alkalay a écrit :
Nicolas, is very hard to discuss opinions and that was your opinion. I respect that, even if I can't understand in what you based this opinion.
Actual shipping software which already behaves like this (server-side, where closed app vendors are already investing in integration), some years working in a software editor etc...
It's way cheaper to write blindly "safe" parameters in a conf file (safe for your part of the system that is) than try to behave nicely with the rest of the system (which may more often than not include the products of your competitors). Especially on the desktop if your bit works and other don't the user will blame the other bits.
The way all existing proprietary software for Linux systematically lags two or three generations behind the FOSS offerings on the integration front (core libs used, oss->alsa migration, core fonts -> fontconfig migration, ia32 -> amd64 transition, selinux...) should tell you where the keyboard manufacturer priorities will be.
My opinion is based mostly in observable evidence on what happened in the Windows world (the good parts), and a bit of intuition.
My opinion is based mostly in observable evidence on what happened in the Windows world (the bad parts), and the fact a lot of the good parts only materialised after MS waving a big stick before app vendors. Plus all I've seen on the Linux front. Your example adds the windows-like "liberty" to fool around and removes the current big stick (clearinghouses).
If elektra succeeds I predict this will be because big organised projects like Gnome or KDE adopt it and force some centralized decisions, not because various app vendors use it to poke holes in settings they shouldn't be allowed to change in the first place.
And I'll freely admit there is demand from app vendors to get the means to fool around like this, except the world in general and my desktop in particular will be a better place if this stays denied to them.
upstream, upstream, upstream as Fedora decided, you should listen to the people at Red Hat which actually have experience on the Linux integration front and take the long term view. Short-circuiting the integration process like you propose is a bad proposition for everyone (including your vendor). Even if its windows habits make it lean this way.
Le lundi 03 avril 2006 à 14:51 -0300, Avi Alkalay a écrit :
Nicolas, is very hard to discuss opinions and that was your opinion. I respect that, even if I can't understand in what you based this opinion.
Avi,
Let's just most software I've seen on the Linux and Windows side (as part of a closed software editor, as a FOSS and closed software integrator) cares very little about the rest of the system. It's oh-so-much easier and cheaper to dump safe (for your bit of software) values in common config files than test values which won't badly affect other parts of the system (as a bonus you can crash your competitors apps sometimes). By being dumb and blind you can save money to implement crucial bits like putting the company logo on every window of your configuration app, paint it in company colors, etc (always a wining point with your PHB, and another reason *not* to integrate with everyone else)
Sanity happens when it's forced top-down by a coordination point, either (in the windows case) MS menacing to retire some crucial support bit (logo, program participation) or (in the FOSS case) some central software clearinghouse (LKML, xorg, fedora) refusing to include some bits before things have been fixed up.
The fact every single closed software offering for Linux lags one or two generations behind in the software integration front (utf-8, selinux, core fonts -> fontconfig, oss -> alsa...) should tell you pretty clearly how high playing nice with the rest of the system is on traditional hardware/software corps agendas.
And your want to give these people the keys to the system conf? Please. I'm sure you can find saner examples than this.
The only companies I've seen in the business that genuinely cared about the system picture are infrastructure companies (OS suppliers, tools vendors like BEA). And they don't need elektra because they already know the system well enough to patch it as need.
(sorry about the duplicate answer, I though my rawhide evo had eaten the previous message when crashing)
On Mon, 2006-04-03 at 12:11 -0300, Avi Alkalay wrote:
On 4/3/06, Horst von Brand vonbrand@inf.utfsm.cl wrote:
That is the crux of the matter: Glorious schemes for world domination "if only everybody will agree on the same configuration file syntax" are thrown around here, but the ones in charge of adopting said syntax have historically shown very, very little desire to agree on a syntax.
Here comes the role of distributions as the integrator. This is why I say each of these projects (Apache, Samba, everything on /etc/*, Gnome, KDE, etc) are a sort of "selfish" and "proprietary" when it comes to overall integration architecture.
Maybe these projects wants something more than just a simple replacement for their configuration file parser?
Maybe parts of their configuration is marked as private and they don't want to make it easy for wanna-be administrators to change it?
Maybe they want to offer an interactive configuration interface based on D-BUS with asynchronous notifications when state in the server changes?
So your idea is getting rid of configuration files and push everything into LDAP? What if the LDAP server is down?
What if you don't have/want a network?
Just run the LDAP server locally. You want some caching LDAP server anyway for disconnected operation.
What if my mother only wants to install a new multimedia keyboard in her standalone Linux box? She'll have to edit /etc/X11/xorg.conf? Or wait for the distribution's HW detection tool to know how to handle that? Clearly the best solutions is to let the HW provider know that X.org configurations are pretty predictable in any distribution, and it just have to provide some scripts to precisely integrate itself in X.org configuration schema, instead of having to "compile", understand and regenerate /etc/X11/xorg.conf only to install itself. Being so difficult, this HW provider will simply, obviously, declare they do not support Linux.
Maybe I'm repeating myself but here goes:
X.org should require no configuration file and should autodetect the software. It should also provide a D-BUS interface to desktop apps can configure the server and it can emit useful asynchronous notifications when e.g. a new monitor is attached. Hence, all display configuration is done per-desktop and settings are read from e.g. gconf. We can do similar tricks of reconfiguring the server on the fly when new hardware is hotplugged. For example you can disable the internal trackpad on a laptop when an external mouse is attached.
Btw, system admins can lock this down if they want and it's trivial to write a display configuration applet that is the same across all distros just like e.g. removable media handling is now the same across all distributions.
For the record, many of (influential) X.org developers with whom I've discussed this agrees this is the road ahead. It's just a lot of work and the people with these skills are busy with other things.
David
On Mon, 2006-04-03 at 02:48 -0400, Horst von Brand wrote:
David Zeuthen david@fubar.dk wrote: my view is that if we solve
it for desktop then the server bits will pan out mostly by itself.
No, the problem spaces are different.
Doesn't have to be.
Bingo! I.e., configuration /is/ needed...
Certainly.
So you advocate not configuring the web server via files, but remotely via LDAP? How is that different from "configuration files"?
It's different insofar that since you already serve configuration from the LDAP server it's next-to-trivial to use the same mechanism to actually change the configuration. Hence, it's a lot easier to write a single configuration UI (or whatever) that all distros can use.
In particular we don't need a all-generic system like Elektra here. And you really want your web server process (e.g. httpd) to know that it reads configuration from the remote end to fix all the corner cases in a nice way.
In any case, this is system-wide, just that your system is larger than one box.
Terminology. That's what I call site-wide.
Great. But that does mean that someone, somewhere has to tweak the configuration (files) with all those desktop settings that the machine gets over the net.
Just add an LDAP backend to gconf and you can control all desktop policy from a central repository. Also look at other approaches for this e.g. Sabayon. Like it or not but gconf is pretty well designed and the "implementation detail" of reading from /etc/gconf or LDAP is just that: an implementation detail.
Hell, once you add LDAP you can go on and refine our UI tools to edit default settings and lock-down from the standard dialogs like for instance the power management dialog
http://www.gnome.org/projects/gnome-power-manager/gpp.html
Maybe this tool would look like this
http://people.freedesktop.org/~david/davidz-evil-admin-console.png (historical note: this mock was done about a year ago)
Plus I'd bet the number of single-machine setups vastly outnumber the multi-client setting you describe, and will for a long time to come. By pushing the problem into the site-wide system administrations hands you have solved nothing.
Site-wide implies something like LDAP to read configuration. Hence, configuration utilities (should they be desirable) can use the same protocol to write settings.
- Things like smb.conf is really not interesting for the desktop
case as it's the wrong solution to the problem of sharing files and using files other systems wants to share. The right answer here is obviously things like Nautilus and gnome-user-share and other things that run in your session and is easy to configure.
Destop has no business in deciding what system-wide resources to share.
Of course it has. Do you expect admins migrating from Windows or Mac OS X to sit down and learn the horror of all the configuration files? Of course not.
My stance is that you want a system where this is configurable from the UI. Even if you want share system wide stuff, maybe this just requires the user to auth in order to allow this.
- X.org having a configuration is completely broken too; obviously
the X.org server should be able to configure itself (and it can but X.org itself has bugs so it doesn't always work) and it should offer a D-BUS interface for reconfiguration so some per-session piece of software can program it with the users setting when your session starts.
Pray tell, where would the user settings come from? Not from a configuration file?!
For GNOME it would of course come from gconf.
I'm not so sure. The display is a system resource.
No, it's per user. Do not pass start. Do not collect $200.
I don't have a good answer to KDE and GNOME sharing configuration; I personally think that as this point it's impossible to get developers of both camp to agree on a scheme for even simple things like desktop backgrounds and HTTP proxies. And should the day come when gconf depends on KConfig, vice versa, or when there is D-Conf I'm sure this will get solved by itself. It sure as hell doesn't need Elektra for this.
That is the crux of the matter: Glorious schemes for world domination "if only everybody will agree on the same configuration file syntax" are thrown around here, but the ones in charge of adopting said syntax have historically shown very, very little desire to agree on a syntax. And (assuming people aren't completely irrational), the very existence of the wildly differing syntaxes tells me there are different needs behind them.
Yes, that's true, however I don't think it's totally important that GNOME and KDE share the setting for e.g. wallpaper. Mostly, I just stick to GNOME apps anyway.
But I'm sure someday there will be some desktop settings that GNOME and KDE will share.
So your idea is getting rid of configuration files and push everything into LDAP? What if the LDAP server is down?
And you need to cache stuff for disconnect operation e.g. laptops. I think Microsoft showed this was possible with AD.
Who says LDAP is the right framework, i.e., is rich enough for the needs? Who says the result won't be just shoveling the garbage into another opaque junkyard?
I'm not saying this is easy. But I am saying we need to be a lot more ambitious than e.g. Elektra. I agree this is a very difficult problem space to navigate in, especially because of the very bazaar nature of open source. It's definitely fixable if we get the right architecture hashed out to begin with.
David
On Mon, 3 Apr 2006, David Zeuthen wrote:
In particular we don't need a all-generic system like Elektra here. And you really want your web server process (e.g. httpd) to know that it reads configuration from the remote end to fix all the corner cases in a nice way.
Here is where we disagree. What you are proposing is a network configuration database which in certain cases I can certainly see the benefit. However it makes much more sense to standardize / unify configuration at the system level and then using a backend to export/import this data to LDAP. This eliminates the single point of failure, less over head, less complexity for normal case and only one program needs to be LDAP configuration aware.
I'm not saying this is easy. But I am saying we need to be a lot more ambitious than e.g. Elektra. I agree this is a very difficult problem space to navigate in, especially because of the very bazaar nature of open source. It's definitely fixable if we get the right architecture hashed out to begin with.
Here is where I think the disconnect is, I agree that a network configuration database is a good idea in theory. I just think the implementation you describe could be better. Elektra and any system designed to be a generic system level configuration engine shouldn't be any more ambitious then it needs to be. It would be easy to add the functionality you are talking about if fedora was 100% elektra enabled.
Cheers, Shane
In my opinion what you write is currently, unfortunately, plain utopia.
I think you got a lot of inspiration about your site-wide writings from MS-AD. As far as I know, AD is not an LDAP. It is a proprietary configuration container which parts of it, not all, can be exported as an LDAP directory. But I'm not a specialist in this subject.
About LDAP being a configuration containter, check this, which I'm not sure also if it is accurate: http://www.libelektra.org/LDAP_and_Other#LDAP
Generaly, you can't get rid of configurations completely. But you can make them so marginal and easy to handle that softwares will interoperate with them by themselves, without asking you many questions.
See, Elektra or any similar thing, is far from being a solution for the configuration problem, but at least it unlocks our current static position of zero-interoperability.
If, in a dream, Elektra or any similar thing gets adopted, the day after will be filled with debates and a lot of work about the better way to define a semantical tree of system parameters. In the second day after, we'll start see programs integrating themselves alone, and higher value being added in the stack. Lack of automatic configuration will be a shadow from the past. While today we are stuck in "proprietary" configuration silos from Apache, Samba, X.org, network, Gnome, KDE, /etc/* , and can't move forward thowards this higher value stack. We are loosing a lot of time dealing with OS internal interoperability, while the rest of the world is making huge steps in the business (higher) value space.
We need to take a lof of steps to achieve the desired utopia you outlined. Elektra is a small first one.
Thank you, Avi
On 4/3/06, David Zeuthen david@fubar.dk wrote:
On Mar 29, 2006, at 7:29 PM, Avi Alkalay wrote:
In addition to the words bellow, the "D" on D-Conf comes from the "Desktop" word, which means D-Conf is a desktop-oriented wannabe- project. You won´t be able to standarize configuration for say named, dhcpd, resolver, sysctl, modprobe, /sbin/init, network configurations, etc etc etc with it.
Speaking of wanna-be. I think one fundamental problem with the LinuxRegistry/Elektra approach is that you try to fix the symptoms of the problem instead of the root problems. I've written about this before and I will do it again and again as apparently people are still trying to fix the symptoms of our problem:
Configuration of software in a mainstream distribution is a mess.
Most of this mail is about the desktop, but really, if you look at it, desktop is _a lot harder_ than server (there is just so much more code and so much more functionality) so my view is that if we solve it for desktop then the server bits will pan out mostly by itself.
It seems that Elektra simply wants to remap the configuration file for a piece "software" into a hierarchical key/value database and I think that's missing the point entirely. First of all you got to ask yourself whether there should be a configuration of said piece of software in the first place. If you think really hard about it you will find that for most pieces of software this is false - you really don't want any configuration files... Hence you really don't want nor need Elektra.
Let us look at what "configuration" really means; I've seen it being used in the following ways
- The programmer is lazy and makes the user look up configuration
values he could have determined programmatically - for example this includes the laptop_mode scripts where you can configure what IDE drives to put to sleep. The poor user will have to put in arcane values such as "/dev/hda", "/dev/hdd" and so forth. You know, maybe the laptop_mode developer wasn't that lazy, maybe the kernel people was just sleeping and gave him no easy way to find out what drives to put to sleep when he wants.. or maybe what the kernel said was unreliable and the kernel never got fixed.... Does this justify bothering the poor end user with crap like this? I think not.
- Configuration can be system-wide, for example mail and web
servers... Sure, my web server needs to know where to serve files from, my mail server needs to know what domain it serves and so forth
- When developers write a daemon and decide to make it system-wide,
then most of the time they either really want it to be site-wide or session-wide instead. Most of the time they don't even know this... I will argue that system-wide is just plain wrong for most things; continue reading...
- Site-wide software: This includes for example a cluster of web
servers. The user experience if I'm an administrator is that I can just plug in another physical server box, PXE-boot it and it reads all "web server configuration" from LDAP. If it blows up I can replace it. Hence, no need at all for having some httpd.conf file. For the (terribly uninteresting) case of only having one machine as a web server it reads settings from the local LDAP server. Ditto with mail servers, name servers etc.
- Session-wide software: Just so we're all on the same page,
"session-wide" means something that runs in a user desktop session. Historically, the desktop wasn't very advanced and didn't integrate well with the system. Back then things that really was session-wide would run as a system-wide daemon mostly also because it required root to enforce policy. Things like acpid for power management event handling, updfstab for removable media, ifplugd for handling network cable removable, networking scripts etc. comes to mind. As you can see with Fedora Core 5 this is radically starting to change; acpid is obsoleted by gnome-power-manager, updfstab (and fstab-sync for that matter) is obsoleted by gnome-volume-manager / gnome-mount, the networking scripts is starting to be completely obsoleted by NetworkManager. We have more things on out "hit list"...
- You really really want session-wide daemons to run in the session
and not as the system because it's much easier for the user to configure it.. in fact, you get per-user settings for removable media handling and power management in FC5. And since all this is backed by gconf it's easy for the OS vendor _and_ the administrator to set sane defaults, lock things down and so forth. It's just a lot better
- Look at the terrible and insecure hacks for writing out
configuration files for system-wide daemons that ought to be session- wide. See also my rant on fedora-maintainers last week why consolehelper (that these tools rely on) is fundamentally flawed.
- Things like smb.conf is really not interesting for the desktop
case as it's the wrong solution to the problem of sharing files and using files other systems wants to share. The right answer here is obviously things like Nautilus and gnome-user-share and other things that run in your session and is easy to configure.
- X.org having a configuration is completely broken too; obviously
the X.org server should be able to configure itself (and it can but X.org itself has bugs so it doesn't always work) and it should offer a D-BUS interface for reconfiguration so some per-session piece of software can program it with the users setting when your session starts. Yes, display configuration is also per-user although the brain dead design of X.org doesn't reflect this.
I don't have a good answer to KDE and GNOME sharing configuration; I personally think that as this point it's impossible to get developers of both camp to agree on a scheme for even simple things like desktop backgrounds and HTTP proxies. And should the day come when gconf depends on KConfig, vice versa, or when there is D-Conf I'm sure this will get solved by itself. It sure as hell doesn't need Elektra for this.
So my message is that I think it's a waste of time trying to shoehorn a configuration file format onto all kinds of software because said software is likely to be already broken for at least desktop use. My stance is simply that it's unacceptable in a desktop system to ever ever have to touch a configuration file and I think some people (*cough* Apple *cough* Microsoft *cough*) take the same stance even for the server. So we shouldn't ship software that rely on them. Hence, there is zero need for Elektra. It's really that simple if you think about it.
I wish that people working on the server bits (e.g. Apache, Postfix) would take a similar stance and only make their software read settings from LDAP (or whatever) for the site-wide case. I think it would be great if you could change Elektra into something that would fix this. But please back off trying to pretend you solve problems for the desktop because you're not. The design of gconf is pretty nice (implementation might be another matter but, you know, that's totally fixable) and it's more than sufficient for desktop use, thank you very much.
Hope this clarifies why Elektra is simply the wrong answer. I'm sorry for sounding harsh and saying most of our software in the distribution is broken, but it's kinda this conclusion I've arrived at. We could do so much better if we all tried to solve the root problems and look at what the user experience should be.
Have a nice day.
DavidDisclaimer : this mail doesn't necessarily reflect the views of Red Hat, Inc.
On Mon, 2006-04-03 at 11:50 -0300, Avi Alkalay wrote:
In my opinion what you write is currently, unfortunately, plain utopia.
Not at all, we're doing this for the desktop already!
This effort is actually called "Project Utopia" :-). Developers love it (both GNOME and KDE adopted the base technology). End users love. Admins tend to somewhat hate it sometimes because "It's new. It's different. And we're always angry." :-)
And for the 1% to 2% use cases we're not there yet so some people with also hate it. We're getting there and, hey, this is open source and we take patches.
<snip>
We need to take a lof of steps to achieve the desired utopia you outlined. Elektra is a small first one.
I just tend to think Elektra is way too generic to be really useful IMHO. What I think you want to do is to engage in a discussion with each upstream project and try to work out the use-cases on how their software is used.
As a matter of fact, I believe that for e.g. Apache a lot of "vertical software" exists (both as proprietary and in-house solutions) for managing clusters of web servers for example. Wouldn't it be nice if Apache adopted one true way of doing this and we could all focus on an UI configuration optimized for this instead of some random Registry Editor?
It's not utopia, it just requires a lot of hard work and effort to do things right. I tend to believe that if you don't do things right the first time you will never get it right because "good enough is the enemy of perfect" or something.
There is no such thing as a free lunch.
David
On 4/3/06, David Zeuthen david@fubar.dk wrote:
On Mon, 2006-04-03 at 11:50 -0300, Avi Alkalay wrote:
In my opinion what you write is currently, unfortunately, plain utopia.
Not at all, we're doing this for the desktop already!
Good to know !
As a matter of fact, I believe that for e.g. Apache a lot of "vertical software" exists (both as proprietary and in-house solutions) for managing clusters of web servers for example. Wouldn't it be nice if Apache adopted one true way of doing this and we could all focus on an UI configuration optimized for this instead of some random Registry Editor?
This is mostly the same problem, being attacked by different fronts. While Elektra tries to do it in a more general fashion in the base of the problem, looks like you guys are trying to improve the Apache silo. Going further in your way seems we are going to have many different improved silos, which will be again not integrated and suitable only for datacenters.
It's not utopia, it just requires a lot of hard work and effort to do things right. I tend to believe that if you don't do things right the first time you will never get it right because "good enough is the enemy of perfect" or something.
Cool, but just take care to create a lot of impenetrable configuration silos, in a model useful only in datacenters.
Regards, Avi
On Mon, Apr 03, 2006 at 01:27:00AM -0400, David Zeuthen wrote:
I wish that people working on the server bits (e.g. Apache, Postfix) would take a similar stance and only make their software read settings from LDAP (or whatever) for the site-wide case.
This always seems like a nice simple idea in theory. The reality is that you'd have to put so much complexity in to deal with stuff like working out what to do during a restart if the LDAP server suddenly stops responding (at the point where you have already thrown away the old config). You also have to come up with (and hard-code!) some LDAP schema; and have it extensible to third-party modules (i.e. generic enough that it's just untyped key-value pairs again). And how do you configure the LDAP connection: TLS, auth, etc? Just relying on the system-wide defaults doesn't cut it for 99% of apps so why would it here? And why only support an LDAP backend? Why not also an SQL database, or a WebDAV repository?
So the reality is that rather than add all that complexity to 50 different daemons, it's better to go and write one single tool which can create flat file configurations from LDAP databases, or SQL databases, or whatever, and can know how to restart the daemons as necessary, and can apply a consistent LDAP schema across the board, etc.
joe
Le Mar 4 avril 2006 15:32, Joe Orton a écrit :
On Mon, Apr 03, 2006 at 01:27:00AM -0400, David Zeuthen wrote:
I wish that people working on the server bits (e.g. Apache, Postfix) would take a similar stance and only make their software read settings from LDAP (or whatever) for the site-wide case.
This always seems like a nice simple idea in theory. The reality is that you'd have to put so much complexity in to deal with...
Also historically FOSS LDAP = openldap and openldap admin is interesting (to say the less).
I don't know how good the netscape stuff is but if manageability is closer to what a normaly constituted human can bear we may see more LDAP use in the next years (which would rock sooooo much for every network constituted from more than 1 node)
Hi Joe,
On Tue, 2006-04-04 at 14:32 +0100, Joe Orton wrote:
On Mon, Apr 03, 2006 at 01:27:00AM -0400, David Zeuthen wrote:
I wish that people working on the server bits (e.g. Apache, Postfix) would take a similar stance and only make their software read settings from LDAP (or whatever) for the site-wide case.
This always seems like a nice simple idea in theory. The reality is that you'd have to put so much complexity in to deal with stuff like working out what to do during a restart if the LDAP server suddenly stops responding (at the point where you have already thrown away the old config). You also have to come up with (and hard-code!) some LDAP schema; and have it extensible to third-party modules (i.e. generic enough that it's just untyped key-value pairs again).
You could be more ambitious and just have a local LDAP proxy that caches values. Yes, this introduces additional complexity.
And how do you configure the LDAP connection: TLS, auth, etc?
Use mDNS and Avahi. Or UPnP. Or whaterver. But don't aim to support everything under the sun... it's just not worth it.. Pick one and go for that.
Just relying on the system-wide defaults doesn't cut it for 99% of apps so why would it here? And why only support an LDAP backend? Why not also an SQL database, or a WebDAV repository?
Because it's crazy to support everything; if you have that goal you end up with a lot of mediocre software.
We have the Fedora Directory Server now, just use that.
And I still want to echo: it's not enough to do this with patches to our own packages. You want to engage upstream of each project and make them buy in to the idea. You potentially want to change how upstream software works in order to support the concept of clusters. You need to make a case for each and every piece of upstream software why this is a good idea.
So the reality is that rather than add all that complexity to 50 different daemons,
50!? Again, the golden rule here is simplicity. Don't task yourself with supporting everything under the sun; pick a few projects that are viable and go with that; for example
- Apache - Postfix - Bind - Some SQL server
and do a good job on them. Do you disagree?
it's better to go and write one single tool which can create flat file configurations from LDAP databases,
No, you really really want to change the way upstream software works. You need to look at the user stories to begin with; if I'm an administrator with at a big site what do I want to do?
- Provisioning of machines; Want to be able to plug in a physical box and automatically make it join my cluster - 99% of users only need Apache, Postfix, Bind, some SQL server or whatever - (add more user stories here)
Start with the user stories, create the architecture, make a plan, implement it. It's _a lot_ of work. Or maybe you think this either is the wrong approach or Utopia?
FWIW, I think what we've been doing / are doing on the desktop with D-BUS/HAL/NetworkManager/g-v-m/g-p-m etc is very similar to this; this too was / is a lot of work. But if you see how people receive then most people like it. Sure, we have some work left (running NM, g-p-m, g-v-m when no one is logged in). Sure, some oldskool hackers like Pete Zaitchev [1] complain about it in a sorta condescending way, but if you read the reviews of FC3, FC4, FC5 you will see that we're going in the right direction.
Yes, so maybe right now the desktop bits are not always suitable for l33t kernel hackers like Pete with very, suffice to say, unusual requirements but down the road we will fill those gaps too. It's just about prioritizing. I expect the same to be true if someone tries to revamp all the server bits.
There is no such thing as a free lunch. But you got to aim high and be ambitious.
David
On Tue, Apr 04, 2006 at 11:20:52AM -0400, David Zeuthen wrote:
On Tue, 2006-04-04 at 14:32 +0100, Joe Orton wrote:
it's better to go and write one single tool which can create flat file configurations from LDAP databases,
No, you really really want to change the way upstream software works.
Why? You're not making a case for that at all. Why can't you do this as an external tool? That is what upstream say, and I certainly agree.
The end goal ("configure everything via LDAP") is no doubt a worthy goal, I don't disagree with that at all. But if it can be achieved by writing one simple tool rather than adding complexity to every daemon (for whatever subset of "every daemon" you find interesting), then why not do that?
I don't think it's particularly useful to draw comparisons with the desktop, FWIW. Things like an HTTP server and an SMTP server are very different to X or any UI tool: they do not tend towards a Utopia of having "zero configuration" based on proper integration with hardware.
Regards,
joe
On Tue, 2006-04-04 at 16:58 +0100, Joe Orton wrote:
On Tue, Apr 04, 2006 at 11:20:52AM -0400, David Zeuthen wrote:
On Tue, 2006-04-04 at 14:32 +0100, Joe Orton wrote:
it's better to go and write one single tool which can create flat file configurations from LDAP databases,
No, you really really want to change the way upstream software works.
Why? You're not making a case for that at all. Why can't you do this as an external tool? That is what upstream say, and I certainly agree.
I suspect that neither you nor "upstream" is looking at user stories.
The end goal ("configure everything via LDAP") is no doubt a worthy goal, I don't disagree with that at all. But if it can be achieved by writing one simple tool
Because it's not that simple for the user experience that at least I think is right.
Here's a user story:
"The administrator David got a message from his boss Brian that the employees are complaining that it takes too long to send email. David looks at the load graphs and says they need more hardware to handle the growth of MiniCorp Inc. David purchases a dual Xeon XYZ box and plugs it into the network. It automatically joins the IMAP and SMTP server clusters and starts serving mail to users. David uses the system admin console to finetune the load balancing of the servers on his cluster and checks that average response time for the IMAP service is now 0.2 seconds, down from 0.6 seconds. David sips some coffee and is happy."
Does it really have to be more difficult? I think not.
rather than adding complexity to every daemon (for whatever subset of "every daemon" you find interesting), then why not do that?
Because it's *hard* and if you look at what user stories are desirable it's just not that simple.
I don't think it's particularly useful to draw comparisons with the desktop, FWIW. Things like an HTTP server and an SMTP server are very different to X or any UI tool: they do not tend towards a Utopia of having "zero configuration" based on proper integration with hardware.
Sorry but I think this is totally unambitious. Near zero-configuration of server daemons, clustered or not, is indeed possible and there's even a whole vertical market for it.
What I'm saying is that instead of doing half-baked solutions like reading one server config at a time via LDAP we should be approaching upstream projects and make their server software cluster aware.
What's wrong with that?
David
On Tue, Apr 04, 2006 at 12:16:14PM -0400, David Zeuthen wrote:
On Tue, 2006-04-04 at 16:58 +0100, Joe Orton wrote:
The end goal ("configure everything via LDAP") is no doubt a worthy goal, I don't disagree with that at all. But if it can be achieved by writing one simple tool
Because it's not that simple for the user experience that at least I think is right.
s/simple tool/tool with single specific purpose/. This is standard Unix philosophy.
You're not making the case that httpd itself needs to be more "cluster aware" or whatever. Your "user story" is great and warm and fuzzy, and can be achieved, AFAICS, by writing a tool which generates httpd configurations, and IMAP server configuration, and whatever, based on some LDAP database. That tool can do all the tricky stuff like having a daemon which polls the LDAP database for changes, knowing when to restart httpd into a new configuration, and knowing how to map a particular LDAP schema into an specific httpd configuration; it can easily scale to supporting lots of different daemons since it's basically the same logic for each. That can all be done without destabilizing the codebases of all the daemons you want to support.
Regards,
joe
Le Mar 4 avril 2006 17:20, David Zeuthen a écrit :
But if you see how people receive then most people like it. Sure, we have some work left (running NM, g-p-m, g-v-m when no one is logged in). Sure, some oldskool hackers like Pete Zaitchev [1] complain about it in a sorta condescending way, but if you read the reviews of FC3, FC4, FC5 you will see that we're going in the right direction.
Yes, so maybe right now the desktop bits are not always suitable for l33t kernel hackers like Pete with very, suffice to say, unusual requirements
They're not unusal requirements. What you've done is what's called a regression, like most regressions it's caused by adding new features users are already thanking you for, and people whose setups you broke have not all noticed it yet and are just starting to curse.
but down the road we will fill those gaps too. It's just about prioritizing. I expect the same to be true if someone tries to revamp all the server bits.
Would it have been so hard to include a server component from the start when people gave you early warnings instead of bolting it in as an afterthought ?
On Tue, 2006-04-04 at 18:11 +0200, Nicolas Mailhot wrote:
They're not unusal requirements. What you've done is what's called a regression, like most regressions it's caused by adding new features users are already thanking you for, and people whose setups you broke have not all noticed it yet and are just starting to curse.
Changing things are painful, I and others realize that, sure. Again, it's about trade offs and prioritization. You can't please 100% of the user base 100% of the time.
Would it have been so hard to include a server component from the start when people gave you early warnings instead of bolting it in as an afterthought ?
Uhm, no one is forcing you to use NetworkManager just yet so there is not really any regression. Btw, the price we pay to support two networking configuration stacks is higher than you think.
David
Le mardi 04 avril 2006 à 12:25 -0400, David Zeuthen a écrit :
On Tue, 2006-04-04 at 18:11 +0200, Nicolas Mailhot wrote:
Would it have been so hard to include a server component from the start when people gave you early warnings instead of bolting it in as an afterthought ?
Uhm, no one is forcing you to use NetworkManager just yet so there is not really any regression.
Which is why people complaining so far are few.
Btw, the price we pay to support two networking configuration stacks is higher than you think.
Probably. But no one advocated two config stacks - just one that took care of the whole problem-space (which includes the no-gui-nor-user-logged-in, many-users-logged-in, gui-user, tui-over-ssh-user)
On Tue, Apr 04, 2006 at 12:25:12PM -0400, David Zeuthen wrote:
Uhm, no one is forcing you to use NetworkManager just yet so there is not really any regression. Btw, the price we pay to support two networking configuration stacks is higher than you think.
By two networking configuration stacks you mean the traditional method and the NetworkManager way? Wouldn't it have been better to have an actual design ... rather than thinking up a GUI interface to some use case, then starting coding?
Pete's condescension is right on target: core Linux components are being replaced by people who, by their own admission, "hate Unix."
It seems that an "unusual requirement" is one that is difficult and inconvenient for that other operating system, i.e., a requirement that foregoes the monkey pressing buttons in front of a bitmapped display.
Unix/Linux carries years of baggage, mis-designed features, and half-baked implementations. But today's GNOME hackers seem to have completely missed the value of (1) text, (2) tools, and (3) domain-specific little languages and protocols. One area where Unix went somewhat astray is that script and config syntax differences created unnecessary impedance [the original point of this thread] -- the Lisp machine folks had that much right. Two decades later, it's easy to see that domain-specific languages are best built without inventing lots of arcane syntax; these days S-exprs have been replaced by XML, XSLT (*vomit*), and worse. Unfortunately, simply stuffing name/value config pairs in a file is not the same as domain-specific design.
I'm not holding my breath waiting for support for 20-year-old "unusual requirements" to be bolted on later.
Bill Rugolsky
On Tue, 2006-04-04 at 13:31 -0400, Bill Rugolsky Jr. wrote:
On Tue, Apr 04, 2006 at 12:25:12PM -0400, David Zeuthen wrote:
Uhm, no one is forcing you to use NetworkManager just yet so there is not really any regression. Btw, the price we pay to support two networking configuration stacks is higher than you think.
By two networking configuration stacks you mean the traditional method and the NetworkManager way?
Correct.
Wouldn't it have been better to have an actual design ... rather than thinking up a GUI interface to some use case, then starting coding?
There is always a fine line and one benefit of getting NM in the distribution early is that it helped moved the kernel networking stack forward insofar that many bugs got fixed. You know (or maybe you don't), the bad rep NetworkManager had for a while is partly due to really really broken drivers.
That and the fact that NetworkManager is pretty useful to a lot of people who happens to have hardware supported by NM.
Pete's condescension is right on target: core Linux components are being replaced by people who, by their own admission, "hate Unix."
Hating UNIX and actually working on providing software that solves real problems without the user having to be computer literate are two completely different things. Yes, I admit to both, but obviously one doesn't imply the other.
The condescension from Pete is not OK in my book because NetworkManager is still not default. For reasons partly related to kernel drivers, partly related to the fact we need a bit more infrastructure to do this right.
It seems that an "unusual requirement" is one that is difficult and inconvenient for that other operating system, i.e., a requirement that foregoes the monkey pressing buttons in front of a bitmapped display.
That's not really a nice thing to say. And NetworkManager is still not default.
Unix/Linux carries years of baggage, mis-designed features, and half-baked implementations. But today's GNOME hackers seem to have completely missed the value of (1) text, (2) tools, and (3) domain-specific little languages and protocols. One area where Unix went somewhat astray is that script and config syntax differences created unnecessary impedance [the original point of this thread] -- the Lisp machine folks had that much right. Two decades later, it's easy to see that domain-specific languages are best built without inventing lots of arcane syntax; these days S-exprs have been replaced by XML, XSLT (*vomit*), and worse. Unfortunately, simply stuffing name/value config pairs in a file is not the same as domain-specific design.
I'm not holding my breath waiting for support for 20-year-old "unusual requirements" to be bolted on later.
NetworkManager is still not the default. I don't think it will be default before it does a lot more what the current default networking stack does including working when no user is logged in.
My view is that Pete is blowing this out of proportion and I think you're just being his puppet in this particular case.
David
Le mardi 04 avril 2006 à 14:00 -0400, David Zeuthen a écrit :
NetworkManager is still not the default. I don't think it will be default before it does a lot more what the current default networking stack does including working when no user is logged in.
My view is that Pete is blowing this out of proportion and I think you're just being his puppet in this particular case.
Well, you know after all the times Gnome people removed functionality because they knew better and future would prove them right, then refused to put them back in even after people did not get used to the new world order ("residual" complaints as Putin says in Chechnia), your declarations of undying love for not-in-gui-session-management can be a tad frightening.
But you can damn Pete for writing what a lot of people were thinking if you like.
On Tue, 2006-04-04 at 20:19 +0200, Nicolas Mailhot wrote:
Well, you know after all the times Gnome people removed functionality because they knew better and future would prove them right, then refused to put them back in even after people did not get used to the new world order ("residual" complaints as Putin says in Chechnia), your declarations of undying love for not-in-gui-session-management can be a tad frightening.
Replacing all the old cruft with new stuff is bound to introduce a few more bugs along the way. I think it's called... progress?
But you can damn Pete for writing what a lot of people were thinking if you like.
That's nice.
At least I learned something today: Never ever propose anything that might be a bit visionary on fedora-devel-list; you will just get shot down by the vocal minority and you will get flamed you for the improvements for the silent majority you helped create.
David
On Tue, 2006-04-04 at 14:36 -0400, David Zeuthen wrote:
At least I learned something today: Never ever propose anything that might be a bit visionary on fedora-devel-list; you will just get shot down by the vocal minority and you will get flamed you for the improvements for the silent majority you helped create.
Well, yah, As is their right.
Half of working on open source software is being able to judge b/t what makes sense to you and what makes sense to any random person. Often times what makes sense to you is correct. Sometimes it is not. I'm not arguing on either side of this whole elektra thing. I'm sure it will shake itself out one way or the t'other.
People will flame, it happens. I think we've all probably be irritated with some design decision at some point and a lot of us have had someone irritated with us b/c of a design decision we made.
It shouldn't stop you from trying or from posting - it should just prepare you for the obvious.
-sv
Hi.
David Zeuthen david@fubar.dk wrote:
Replacing all the old cruft with new stuff is bound to introduce a few more bugs along the way. I think it's called... progress?
Replacing old cruft with new stuff is called "replacing old cruft with new stuff", technically. It becomes "progress" when things improve somewhere along the way.
That's not to say that NM isn't progress, mark.
Le mardi 04 avril 2006 à 14:36 -0400, David Zeuthen a écrit :
Replacing all the old cruft with new stuff is bound to introduce a few more bugs along the way. I think it's called... progress?
But you can damn Pete for writing what a lot of people were thinking if you like.
That's nice.
At least I learned something today: Never ever propose anything that might be a bit visionary on fedora-devel-list; you will just get shot down by the vocal minority and you will get flamed you for the improvements for the silent majority you helped create.
David,
Please take it with a grain of salt. People don't have to agree with all your write. I somehow agree on the ldap part coming handy (I wrote it some messages before). I also agreed on some of your other points. On this particular one I disagreed with you. Pete disagreed with you. Bill disagreed with you. Maybe that means this particular part of your vision is wrong ? Or miscommunicated ?
Nothing you wrote so far was intended to assuage people's fear. The (shall I write it) contempt you've shown for historic RHL/Fedora users and their needs also did not help. Where do you think Fedora would be if they betrayed you like you seem intent on and let you drool over Bill lobotomised users without any grassroot support ? (why do you think Red Hat revived Fedora after letting it wither a few years)
Your communication was very poor and I have some great examples of it at home. One of them put 3 million people on the streets last week. Then because someone was listening very hard to the silent majority and not to what people where actually saying it put 3 million people in the streets again today.
The fact is even if the vocal minority is a minority, it's actually telling you things. OTOH you could completely misunderstand the silent majority and be none the wiser. The silent majority is difficult to understand. It doesn't speak loudly at all.
On Tue, 2006-04-04 at 21:09 +0200, Nicolas Mailhot wrote:
Nothing you wrote so far was intended to assuage people's fear. The (shall I write it) contempt you've shown for historic RHL/Fedora users and their needs also did not help. Where do you think Fedora would be if they betrayed you like you seem intent on and let you drool over Bill lobotomised users without any grassroot support ? (why do you think Red Hat revived Fedora after letting it wither a few years)
umm. what? When did red hat let fedora wither?
Your communication was very poor and I have some great examples of it at home. One of them put 3 million people on the streets last week. Then because someone was listening very hard to the silent majority and not to what people where actually saying it put 3 million people in the streets again today.
umm What? when did something ANYONE say in fedora put 3 million people in the streets?
I hope you're engaging in hyperbole.
-sv
Le mardi 04 avril 2006 à 15:19 -0400, seth vidal a écrit :
On Tue, 2006-04-04 at 21:09 +0200, Nicolas Mailhot wrote:
(why do you think Red Hat revived Fedora after letting it wither a few years)
umm. what? When did red hat let fedora wither?
deemphasised if you want to be politically correct (RHL 8 to FC-2 or 3 I think) Then the press releases started rolling again and Fedora was not the ugly duckling anymore.
On Tue, 2006-04-04 at 21:31 +0200, Nicolas Mailhot wrote:
Le mardi 04 avril 2006 à 15:19 -0400, seth vidal a écrit :
On Tue, 2006-04-04 at 21:09 +0200, Nicolas Mailhot wrote:
(why do you think Red Hat revived Fedora after letting it wither a few years)
umm. what? When did red hat let fedora wither?
deemphasised if you want to be politically correct (RHL 8 to FC-2 or 3 I think) Then the press releases started rolling again and Fedora was not the ugly duckling anymore.
the release announcements went out for every release.
-sv
On Tue, 2006-04-04 at 21:31 +0200, Nicolas Mailhot wrote:
deemphasised if you want to be politically correct (RHL 8 to FC-2 or 3 I think) Then the press releases started rolling again and Fedora was not the ugly duckling anymore.
If anything, it was the media who no longer saw it as the ugly duckling. Red Hat is doing not much more, not much less marketing and such around Fedora, those in the media space are finally paying attention. A lot of that has to do with the Fedora community beating media folks over the head with our correct information and such.
Le mardi 04 avril 2006 à 21:31 +0200, Nicolas Mailhot a écrit :
Le mardi 04 avril 2006 à 15:19 -0400, seth vidal a écrit :
On Tue, 2006-04-04 at 21:09 +0200, Nicolas Mailhot wrote:
(why do you think Red Hat revived Fedora after letting it wither a few years)
umm. what? When did red hat let fedora wither?
deemphasised if you want to be politically correct (RHL 8 to FC-2 or 3 I think) Then the press releases started rolling again and Fedora was not the ugly duckling anymore.
Which makes me think (slow thinker that I am) now that this period is over could we add a Fedora History page in the wiki with the "eat your brainz" satire ?
Or is it still too early ?
On Tue, 2006-04-04 at 21:41 +0200, Nicolas Mailhot wrote:
Le mardi 04 avril 2006 à 21:31 +0200, Nicolas Mailhot a écrit :
Le mardi 04 avril 2006 à 15:19 -0400, seth vidal a écrit :
On Tue, 2006-04-04 at 21:09 +0200, Nicolas Mailhot wrote:
(why do you think Red Hat revived Fedora after letting it wither a few years)
umm. what? When did red hat let fedora wither?
deemphasised if you want to be politically correct (RHL 8 to FC-2 or 3 I think) Then the press releases started rolling again and Fedora was not the ugly duckling anymore.
Which makes me think (slow thinker that I am) now that this period is over could we add a Fedora History page in the wiki with the "eat your brainz" satire ?
Or is it still too early ?
I'm pretty sure we have the brane satire somewhere. If not google has it. :)
-sv
On Tue, 2006-04-04 at 14:36 -0400, David Zeuthen wrote:
On Tue, 2006-04-04 at 20:19 +0200, Nicolas Mailhot wrote:
Well, you know after all the times Gnome people removed functionality because they knew better and future would prove them right, then refused to put them back in even after people did not get used to the new world order ("residual" complaints as Putin says in Chechnia), your declarations of undying love for not-in-gui-session-management can be a tad frightening.
Replacing all the old cruft with new stuff is bound to introduce a few more bugs along the way. I think it's called... progress?
Getting rid of old cruft is fine. It's just that some of the changes made in the past have broken features that are central to expectations of how Unix systems should operate. People are worried that these great new changes are going to leave us with a trail of broken behavior among the features that made us start using Linux and Unix in the first place. Saying the new interface is more intuitive and better does not allay these worries, rather it adds to people's fears that the developers are not concerned about breaking the way Linux and Unix have always worked because the developers "know better". To make those worries go away, the "new stuff" has to learn to do the right thing for those old ways of doing things.
At least I learned something today: Never ever propose anything that might be a bit visionary on fedora-devel-list; you will just get shot down by the vocal minority and you will get flamed you for the improvements for the silent majority you helped create.
Visionary is fine. But as a developer of the new technology you have to keep in mind the features of the present system that users actually like and figure out how to keep your changes from compromising them.
From my understanding of the technologies, I don't see anything wrong with their design. But the implementations have been geared towards doing things through a sparkly new graphical UI and user-managed services with little (perceived?) work enabling the equivalent commandline functions or how to divide permissions when the administrator wants the resource to be managed system-wide.
In other words, great start! but you can't consider it a job well done until you've paid the same attention to usability on the command line as on the desktop and figured out how system-wide settings interact with per-user.
-Toshio
David Zeuthen wrote:
Replacing all the old cruft with new stuff is bound to introduce a few more bugs along the way. I think it's called... progress?
On legacy operating systems, it turned out to be actually a dead end.
But you can damn Pete for writing what a lot of people were thinking if you like.
That's nice.
At least I learned something today: Never ever propose anything that might be a bit visionary on fedora-devel-list; you will just get shot down by the vocal minority and you will get flamed you for the improvements for the silent majority you helped create.
As a sysadmin I might be a part of the vocal minority, and I actually agree that many of the problems you want to address are there and need to be addressed - it's just that, and I believe many of the others are actually trying to say just this, the proposed vision carries along a price we're not willing to pay.
Just my $0.02, Davide Bolcioni
On 4/5/06, Davide Bolcioni db-fedora@3di.it wrote:
As a sysadmin I might be a part of the vocal minority, and I actually agree that many of the problems you want to address are there and need to be addressed - it's just that, and I believe many of the others are actually trying to say just this, the proposed vision carries along a price we're not willing to pay.
A useful cmdline tool to interact with dbus would go a long long way. Something for dbus which is at least as functional a tool as gconftool is for gconf.
A cmdline tool that exposed introspection as to what methods were available over the bus so admins can ask questions with regard to what clients and methods are currently active on the bus and introspection per method so we can ask what arguments a particular method takes without having to dig up an API document PER DBUS CLIENT to figure out what methods take what arguments PER CLIENT. To make use of dbus and anything which is expected to communicate over dbus I need a tool designed to navigate the dbus space on the cmdline. Something I can use to explore the space, discover which services are available and how to communicate which each service, so I can then script actions or fire off individual actions over remote concole connections if required.
dbus-send right now allows me to script actions across dbus, but without the introspection tool to explore the space dbus will continue to be under utilized for sysadmin actions... and thats going to be a big big problem moving forward. Because as more services expect to be controlled over dbus, admins will be using other approaches they are more comfortable with because the minimal set of cmdline tools to interact with dbus are not available.
dbus definitely has potential as a very powerful sysadmin oriented technology. It's certaintly not a bad technology but it needs a cmdline oriented interface with introspection to be approachable enough for sysadmins to start working with it to solve their specific local policy/action needs. I encourage everyone to take a look at the oddjob package in Extras to see one direction in which dbus can be taken to morph it into something useful for a sysadmin.
-jef
On Wed, 5 Apr 2006, Jeff Spaleta wrote:
A useful cmdline tool to interact with dbus would go a long long way. Something for dbus which is at least as functional a tool as gconftool is for gconf.
I am curious what type of interactions do you for-see admins performing with dbus? I am not that familiar with dbus but it sounds interesting, it is unclear to me how an admin would use it though.
Cheers, Shane
On 4/5/06, Shane Stixrud shane@geeklords.org wrote:
On Wed, 5 Apr 2006, Jeff Spaleta wrote:
A useful cmdline tool to interact with dbus would go a long long way. Something for dbus which is at least as functional a tool as gconftool is for gconf.
I am curious what type of interactions do you for-see admins performing with dbus? I am not that familiar with dbus but it sounds interesting, it is unclear to me how an admin would use it though.
How exactly do i answer that if you aren't familiar with dbus? I suggest you look at oddjob in Extras, which lets you define simple dbus clients that wrap common admin actions so that you can communicate over dbus to fire off those actions. I think if you are able to understand how to use oddjob then you will understand why I think having a cmdline tools which allows for instrospection over the bus would be invaluable to help admins learn how to use dbus communication effectively. oddjob is the first software implementation that I've seen that attempts to harness the power of dbus communications as a tool for sysadmin tasks instead of streamlining the desktop user oriented experience at the application level. Introspection isn't so important when dbus as a sort of back-channel for application-to-application communication... but its definitely much more important when dbus is exposed directly as a tool to help sysadmin's better organize the janitorial crap they have to do locally on their systems.
-jef
Le mercredi 05 avril 2006 à 12:12 -0700, Shane Stixrud a écrit :
On Wed, 5 Apr 2006, Jeff Spaleta wrote:
A useful cmdline tool to interact with dbus would go a long long way. Something for dbus which is at least as functional a tool as gconftool is for gconf.
I am curious what type of interactions do you for-see admins performing with dbus? I am not that familiar with dbus but it sounds interesting, it is unclear to me how an admin would use it though.
Components expose actions via dbus -> obvious sysadmin scripting target Components expose events via dbus -> you could write triggers (instead of polling cron jobs), logging/supervision scripts. Plugging nagios on d-bus might be interesting
Of course if the perfect GUI admin app existed there would be no need for manual sysadmin action, but if systems didn't have to be cobbled together all the time there would be little need of administering in the first place.
On Tue, 4 Apr 2006, David Zeuthen wrote:
Hating UNIX and actually working on providing software that solves real problems without the user having to be computer literate are two completely different things. Yes, I admit to both, but obviously one doesn't imply the other.
The condescension from Pete is not OK in my book because NetworkManager is still not default. For reasons partly related to kernel drivers, partly related to the fact we need a bit more infrastructure to do this right.
I think the worry is this: the lack of concern shown for backwards compatibility, needs of command-line users, etc. to date suggests that when it does become the default it will be the same sort of half-baked cock-up as was introduced in FC5 by gnome-mount....
later, chris
On Tue, Apr 04, 2006 at 02:00:14PM -0400, David Zeuthen wrote:
My view is that Pete is blowing this out of proportion and I think you're just being his puppet in this particular case.
Heh, I'm quite capable of thinking for myself, thank you. My thoughts on this and related topics are in the relevant archives ...
As for blowing things out of proportion, take it for what it is: a lament that a mis-design will come into sufficiently wide-spread use that it will draw interest and resources away from a much better solution. And once it is "good enough" for your "typical" use cases, interest in covering the rest of the cases will wane.
But there's no requirement that any of us accept gifts that we don't want, and NetworkManager, like any other free software, is a gift. So honestly, I have no sense of entitlement, just bemusement.
Bill Rugolsky
On Tue, 4 Apr 2006 13:31:57 -0400, "Bill Rugolsky Jr." brugolsky@telemetry-investments.com wrote:
Pete's condescension is right on target: core Linux components are being replaced by people who, by their own admission, "hate Unix."
There was no condescension, please take this back. And I never touched the subject of hate of Unix. What is up with putting words in my mouth here?
Since we're on the topic, I do not mind if someone hates Unix, as long as he knows Unix, so he is not doomed to reinvent it, poorly.
-- Pete
On Tue, Apr 04, 2006 at 11:34:27AM -0700, Pete Zaitcev wrote:
Pete's condescension is right on target: core Linux components are being replaced by people who, by their own admission, "hate Unix."
There was no condescension, please take this back. And I never touched the subject of hate of Unix. What is up with putting words in my mouth here?
Didn't mean to put words in your mouth. David referred to it as condescension, my repetition of that word was merely in reference to his comment. I should have put it in scare quotes.
The "hate Unix" reference is from David's own comments regarding your blog.
Apologies.
Since we're on the topic, I do not mind if someone hates Unix, as long as he knows Unix, so he is not doomed to reinvent it, poorly.
I wonder what Henry Spencer would say about reinventing Windows 98 poorly as a warmup exercise.
-Bill
Bill Rugolsky Jr. wrote:
By two networking configuration stacks you mean the traditional method and the NetworkManager way? Wouldn't it have been better to have an actual design ... rather than thinking up a GUI interface to some use case, then starting coding?
Pete's condescension is right on target: core Linux components are being replaced by people who, by their own admission, "hate Unix."
Well, the former goes hand in hand with the latter, apparently. There is a saying: "Those that don't understand Unix are comdemned to reimplement it ... poorly".
It seems that an "unusual requirement" is one that is difficult and inconvenient for that other operating system, i.e., a requirement that foregoes the monkey pressing buttons in front of a bitmapped display.
The irony is that legacy operating systems are moving in the opposite direction, introducing text, tools and domain-specific little languages.
Unix/Linux carries years of baggage, mis-designed features, and half-baked implementations. But today's GNOME hackers seem to have completely missed the value of (1) text, (2) tools, and (3) domain-specific little languages and protocols. One area where Unix went somewhat astray is that script and config syntax differences created unnecessary impedance [the original point of this thread] -- the Lisp machine folks had that much right. Two decades later, it's easy to see that domain-specific languages are best built without inventing lots of arcane syntax; these days S-exprs have been replaced by XML, XSLT (*vomit*), and worse.
In my experience, XML does not really work for domain specific languages because it is too heavy on syntax baggage for humans - it is best thought of as textual XDR: good for program-to-program data interchange. I believe your reaction to XSLT confirms this.
Unfortunately, simply stuffing name/value config pairs in a file is not the same as domain-specific design.
I'm not holding my breath waiting for support for 20-year-old "unusual requirements" to be bolted on later.
Davide Bolcioni
From: "David Zeuthen" david@fubar.dk
Uhm, no one is forcing you to use NetworkManager just yet so there is not really any regression.
I fear the day when we'll have to use NetworkManager, based on responses that I got to my complain: https://www.redhat.com/archives/fedora-devel-list/2005-July/msg00413.html
Again, the classical "you are not our use case". Not "sorry, we screwed up", not "we hope to fix it in the future".
I mean, NetworkManager was going an idiotic thing: overwriting my manually created file without doing at least a backup. Not to mention use the stuff I've put in there, or try to restore it when it's done.
And the answer from people that should know better is: "we don't care, you are not our user".
Surely you don't think this gives folks the warm and fuzzies.
On Tue, 2006-04-04 at 14:42 -0400, Dimi Paun wrote:
From: "David Zeuthen" david@fubar.dk
Uhm, no one is forcing you to use NetworkManager just yet so there is not really any regression.
I fear the day when we'll have to use NetworkManager, based on responses that I got to my complain: https://www.redhat.com/archives/fedora-devel-list/2005-July/msg00413.html
Again, the classical "you are not our use case". Not "sorry, we screwed up", not "we hope to fix it in the future".
I didnt read it that way. Thats why I depend on specific bug reports rather than rants on mailing lists to solve problems.
Rahul
Hi.
On Tue, 04 Apr 2006 11:20:52 -0400, David Zeuthen wrote:
Yes, so maybe right now the desktop bits are not always suitable for l33t kernel hackers like Pete with very, suffice to say, unusual requirements
I do not consider having a working network connection even if noone is currently logged in an "unusual requirement".
On 4/4/06, Joe Orton jorton@redhat.com wrote:
On Mon, Apr 03, 2006 at 01:27:00AM -0400, David Zeuthen wrote:
I wish that people working on the server bits (e.g. Apache, Postfix) would take a similar stance and only make their software read settings from LDAP (or whatever) for the site-wide case.
This always seems like a nice simple idea in theory. The reality is that you'd have to put so much complexity in to deal with stuff like working out what to do during a restart if the LDAP server suddenly stops responding (at the point where you have already thrown away the old config). You also have to come up with (and hard-code!) some LDAP schema; and have it extensible to third-party modules (i.e. generic enough that it's just untyped key-value pairs again). And how do you configure the LDAP connection: TLS, auth, etc? Just relying on the system-wide defaults doesn't cut it for 99% of apps so why would it here? And why only support an LDAP backend? Why not also an SQL database, or a WebDAV repository?
I also think LDAP adds a considerable ammount of complexity with its need for a schema, was not designed for this purpose, adds risk of network unavailability, makes no sense in single computer environments, and is wrongly inspired in AD, because AD is not LDAP: it is more than LDAP, and some parts of it can be represented as an LDAP server.
On the other hand, if these softwares are elektrified, you can point their configurations to be read from the network, just switching the key database backend. This is transparent to the application.
Regards, Avi
On Tue, 2006-04-04 at 12:48 -0300, Avi Alkalay wrote:
On the other hand, if these softwares are elektrified, you can point their configurations to be read from the network, just switching the key database backend. This is transparent to the application.
But Elektra is just not good enough for this. You really really want to change the upstream software to *know* about the fact that it's reading configuration from a central repository. Said central repository will contain information that the a node can process in order to configure itself as part of the cluster. Hence, part of the configuration needs to contain the site-wide bits. This is important. Do you disagree?
So.. you can never do this with a hack like Elektra. Networking is *hard*, saying "This is transparent to the application" is just a cop out since it doesn't handle many important cases such as "what's the default configuration for new nodes".
In fact, I'd argue adopting Elektra is counter productive to getting upstream software to start thinking like this and it's why it's so dangerous to just start adopting Elektra. You can call this an Utopian dream all day long, but I guess where we differ is that you say Elektra is one step in the right direction towards the Utopia dream that I think we share. I argue it's actually a step in the wrong direction.
Good enough is the enemy of perfect. And in Fedora we should not sell out and settle for "good enough".
David
On Tue, 4 Apr 2006, David Zeuthen wrote:
On Tue, 2006-04-04 at 12:48 -0300, Avi Alkalay wrote:
On the other hand, if these softwares are elektrified, you can point their configurations to be read from the network, just switching the key database backend. This is transparent to the application.
But Elektra is just not good enough for this. You really really want to change the upstream software to *know* about the fact that it's reading configuration from a central repository. Said central repository will contain information that the a node can process in order to configure itself as part of the cluster. Hence, part of the configuration needs to contain the site-wide bits. This is important. Do you disagree?
Can you give an example of when one would want to make an application aware that it is "reading configuration from a central repository?". In most of the cases I can think the applications care not where it gets the data as long as it gets it. In the cases where it does need to know it is a central store, if you are going to have to make the application aware of that anyways why not just tag those keys that should/need be centralized as such, you could even have a sub-hierarchy under elektra for all of these keys i.e. /system/sw/someapp/netcfg/keys /system/sw/someapp/otherpaths/otherskeys
Cheers, Shane
On Tuesday 28 March 2006 23:45, Shane Stixrud wrote:
A serious question for you Jeff, would XML exist in any applications today if it were developed by a few people in some basement and the authors went around trying to convince upstream projects to use it? Let's get real.
And ... that's not an argument in favour of elektra, or anything else.
Ad hominem arguments aren't, generally. Although a generally useful one is to actually pick on a real weakness.
On Tue, 2006-03-28 at 14:37 -0800, Shane Stixrud wrote:
On Tue, 28 Mar 2006, Toshio Kuratomi wrote:
If you look through the following, monster thread you'll find that elektra is a bad choice for the desktop configuration api. System and desktop configuration requirements are different. Also, the author of that GConf comparison doesn't seem to understand the problems GConf is attempting to solve which doesn't bode well for it ever displacing GConf.
If I am not mistaken since that time elektra has developed its backends so that they can import/modify/export data from other systems like gconf so that gnome can continue to depend on gconf while users/admins can have a single method of modifying data.
Hmm... but what is really the goal of the project? To have a unified on-disk format? Or to have a unified API? Reading through the myriad posts and Documentation leaves me with the feeling that which one it is depends on which suits them at the time. Elektra using a Gconf backend would give you a unified API -- but if the GConf API is more suitable for the desktop than Elektra then what are you gaining?
OTOH, if the on-disk-format is what's important (so the system admin can edit the text files consistently) then Elektra would have to be the backend for GConf (which is possible, contrary to the implication on http://www.libelektra.org/GConf )
In either case Elektra may very well not be the correct solution, but a technical solution does exist, it may just not of been found/developed yet. There is a problem to be solved here, I haven't heard anyone argue seriously to the contrary
I think Nicholas Mailhot had an extremely valid point: The configuration format (key = value; <key>value</key>; etc) is not a major stumbling block for a system admin. It's what the application developers choose as the name for key and what they fill value with that make configuration files easy or hard to understand. Elektra and the like are seeking to solve a problem that will only marginally aid a system administrator in editing a config file from a text editor.
-Toshio
Just fantasising here ... the ideal configuration system IMHO would fulfil the following criteria:
1. For simple configurations it should reduce to a simple key-value pair text file, except that parsing rules will be very well defined. 2. At the other end of the scale it should handle the most complex applications 3. An optional schema definition can define the schema of the file 4. That schema can optionally provide enough information to enable a configuration file editor to automatically generate a UI to enable someone who is not intimate with the application to make changes (help text, widget hints etc) 5. I18N proof 6. Optional modification history and roll back facility. If the modification was made programatically, the audit trail should record what make the modification. 7. Always have the option to edit with a text editor (ie it should be easy for a human to read it and edit it) 8. API bindings for common languages (C, C++, Python, Java, Perl, bash?)
Joe.
On 3/28/06, Toshio Kuratomi toshio@tiki-lounge.com wrote:
On Tue, 2006-03-28 at 14:37 -0800, Shane Stixrud wrote:
On Tue, 28 Mar 2006, Toshio Kuratomi wrote:
If you look through the following, monster thread you'll find that elektra is a bad choice for the desktop configuration api. System and desktop configuration requirements are different. Also, the author of that GConf comparison doesn't seem to understand the problems GConf is attempting to solve which doesn't bode well for it ever displacing GConf.
If I am not mistaken since that time elektra has developed its backends so that they can import/modify/export data from other systems like gconf so that gnome can continue to depend on gconf while users/admins can have a single method of modifying data.
Hmm... but what is really the goal of the project? To have a unified on-disk format? Or to have a unified API? Reading through the myriad posts and Documentation leaves me with the feeling that which one it is depends on which suits them at the time. Elektra using a Gconf backend would give you a unified API -- but if the GConf API is more suitable for the desktop than Elektra then what are you gaining?
OTOH, if the on-disk-format is what's important (so the system admin can edit the text files consistently) then Elektra would have to be the backend for GConf (which is possible, contrary to the implication on http://www.libelektra.org/GConf )
In either case Elektra may very well not be the correct solution, but a technical solution does exist, it may just not of been found/developed yet. There is a problem to be solved here, I haven't heard anyone argue seriously to the contrary
I think Nicholas Mailhot had an extremely valid point: The configuration format (key = value; <key>value</key>; etc) is not a major stumbling block for a system admin. It's what the application developers choose as the name for key and what they fill value with that make configuration files easy or hard to understand. Elektra and the like are seeking to solve a problem that will only marginally aid a system administrator in editing a config file from a text editor.
-Toshio
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQBEKb/iX6yAic2E7kgRApBAAJ9ZecfzBkoDI6RlUtNmDoImkSwjzwCfWSwr KLRWkDMJ2mCemySz5XQ95L0= =gvoY -----END PGP SIGNATURE-----
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Wed, 29 Mar 2006, Joe Desbonnet wrote:
Just fantasising here ... the ideal configuration system IMHO would fulfil the following criteria:
- For simple configurations it should reduce to a simple key-value
pair text file, except that parsing rules will be very well defined. 2. At the other end of the scale it should handle the most complex applications 3. An optional schema definition can define the schema of the file 4. That schema can optionally provide enough information to enable a configuration file editor to automatically generate a UI to enable someone who is not intimate with the application to make changes (help text, widget hints etc) 5. I18N proof 6. Optional modification history and roll back facility. If the modification was made programatically, the audit trail should record what make the modification. 7. Always have the option to edit with a text editor (ie it should be easy for a human to read it and edit it) 8. API bindings for common languages (C, C++, Python, Java, Perl, bash?)
Add to that list: designed to to be minimal enough to be desirable for system initialization, fstab, modules.conf etc..
A name space that is designed to account for and scale from fstab to web apps.
And most importantly every key should be required to have at least a short description that is I18N compatible.
Shane
On Tue, 28 Mar 2006 14:59:48 -0800 Toshio Kuratomi toshio@tiki-lounge.com wrote:
I think Nicholas Mailhot had an extremely valid point: The configuration format (key = value; <key>value</key>; etc) is not a major stumbling block for a system admin. It's what the application developers choose as the name for key and what they fill value with that make configuration files easy or hard to understand. Elektra and the like are seeking to solve a problem that will only marginally aid a system administrator in editing a config file from a text editor.
System administration of say dhcp or dns or any other service on Windows isn't easier because of a unified key/value system. And clearly it has nothing to do with an ability to read well-named registry keys (what a nightmare). It's easier because of better and more functionally complete GUI administration tools. The same strategy should make Linux easier to administor for those looking to make the jump. And it has the upside of not requiring a grand unified plan.
As i've said in quite a few posts I agree with your conclusion, a common configuration registry will only improve things marginally.
Sean
On 3/28/06, Toshio Kuratomi toshio@tiki-lounge.com wrote:
I think Nicholas Mailhot had an extremely valid point: The configuration format (key = value; <key>value</key>; etc) is not a major stumbling block for a system admin. It's what the application developers choose as the name for key and what they fill value with that make configuration files easy or hard to understand. Elektra and the like are seeking to solve a problem that will only marginally aid a system administrator in editing a config file from a text editor.
Yeah, thats because Elektra main goal is not to help sysadmins, but to help unrelated programs to colaborate automaticaly. this way, helping the sysadmin is an inevitable consequence.
How many times you see regular non-sysadmin Windows users dealing with low level configurations? The answer is exactly "never", because the applications can do this task for themselves instead of asking the user to edit this and that configurations to make all work correctly.
Of course Elektra adds a considerable amount of security and filesystem-like access permissions, compared to what Microsoft did with the their registry.
Avi
On Thu, 30 Mar 2006, Avi Alkalay wrote:
Yeah, thats because Elektra main goal is not to help sysadmins, but to help unrelated programs to colaborate automaticaly. this way, helping the sysadmin is an inevitable consequence.
It seems to me configuration data in an Elektra like format DOES help sysadmins with managing system configuration even without fancy applications. The sysadmin just needs to begin treating configuration data as a series of "command directives" instead big bang application/subsystem file edits.
With the right type of command line viewer / editor read-ability of raw config actually improves IMO.
example:
cfg_mgr -interactive
display /dhcp/sw/dhcpd/subnets/10.202.46.0-24/*
use-host-decl-names = on options/log-servers = 10.202.46.2 hosts/ws001/fixed-address = 192.168.0.1 hosts/ws001/default-lease-time = 10000 hosts/ws001/filename = /lts/vmlinuz-2.4.26-ltsp-1 hosts/ws001/hw = ethernet:00:11:22:33:44:55
edit -format (ini,xml,text etc...) /dhcp/sw/dhcpd/subnets/10.202.46.0-24/
vi/emacs etc.. starts up with the the above information in the specified format (xml, ini, plain text) and the admin may now change values, add new hosts, options etc... as though it was a file.
The above functionality would just as easily be accessible via the command prompt with the right -switches.
Cheers, Shane
On Wed, 29 Mar 2006, Shane Stixrud wrote:
On Thu, 30 Mar 2006, Avi Alkalay wrote:
Yeah, thats because Elektra main goal is not to help sysadmins, but to help unrelated programs to colaborate automaticaly. this way, helping the sysadmin is an inevitable consequence.
It seems to me configuration data in an Elektra like format DOES help sysadmins with managing system configuration even without fancy applications. The sysadmin just needs to begin treating configuration data as a series of "command directives" instead big bang application/subsystem file edits.
example:
[snip]
Or even better the following is very readable and easy to edit with a standard text editor IMO.
cfg_mgr --interactive
display -detail /dhcp/sw/dhcpd/subnets/10.202.46.0-24/*
/use-host-decl-names: ; Key description # User comments go here on
/options/log-servers: ; Key description # User comments go here 10.202.46.2, 10.202.46.3
/hosts/ws001/fixed-address: ; Key description # User comments go here 192.168.0.1
/hosts/ws001/default-lease-time: ; Key description # User comments go here 10000
/hosts/ws001/filename: ; Key description # User comments go here /lts/vmlinuz-2.4.26-ltsp-1
/hosts/ws001/hw: ; Key description # User comments go here ethernet:00:11:22:33:44:55
On Wed, 29 Mar 2006 21:56:41 -0800 (PST) Shane Stixrud shane@geeklords.org wrote:
Or even better the following is very readable and easy to edit with a standard text editor IMO.
cfg_mgr --interactive
display -detail /dhcp/sw/dhcpd/subnets/10.202.46.0-24/*
/use-host-decl-names: ; Key description # User comments go here on
/options/log-servers: ; Key description # User comments go here 10.202.46.2, 10.202.46.3
/hosts/ws001/fixed-address: ; Key description # User comments go here 192.168.0.1
/hosts/ws001/default-lease-time: ; Key description # User comments go here 10000
/hosts/ws001/filename: ; Key description # User comments go here /lts/vmlinuz-2.4.26-ltsp-1
/hosts/ws001/hw: ; Key description # User comments go here ethernet:00:11:22:33:44:55
For ad-hoc interactive usage that looks worse than what we have today; call up a config file and page through it to see the information you want. However something like that might be useful for scripting.
But the difficult issue isn't really what tools might be possible after a unified config system is in place. Rather, it's how to get enough apps to use the config system in the first place. My own view is that concentrating on the needs of _developers_ not users and sysadmins is the way to success. The user and admin tools are the easy part.
Sean
On Thu, 30 Mar 2006, sean wrote:
For ad-hoc interactive usage that looks worse than what we have today; call up a config file and page through it to see the information you want.
It is but one possible example. My point is how the keys and values are formated is flexible, the hierarchical key/value pair storage medium contains all of information required to recreate the dhcpd.conf file in its entirety. The key descriptions and user comments can be stored as "files" associated with these same directories/keys and then compiled+arranged on demand for user consumption.
Perhaps this example is more to your liking?:
cfg_mgr --interactive
display -embed -nodesc -comments /dhcp/sw/dhcpd/subnets/10.202.46.0-24/*
10.202.46.0-24 { # User comments go here use-host-decl-names = on }
options { # User comments go here log-servers = 10.202.46.2, 10.202.46.3 }
hosts { ws001 { # User comments go here fixed-address = 192.168.0.1 # User comments go here default-lease-time = 10000 # User comments go here filename = /lts/vmlinuz-2.4.26-ltsp-1 # User comments go here hw = ethernet:00:11:22:33:44:55 } } }
But the difficult issue isn't really what tools might be possible after a unified config system is in place. Rather, it's how to get enough apps to use the config system in the first place. My own view is that concentrating on the needs of _developers_ not users and sysadmins is the way to success. The user and admin tools are the easy part.
I agree the tools shouldn't be the focus, my point though is the with the right storage design / medium existing tools would be usable.
Cheers, Shane
On 3/28/06, Toshio Kuratomi toshio@tiki-lounge.com wrote:
If you look through the following, monster thread you'll find that elektra is a bad choice for the desktop configuration api. System and desktop configuration requirements are different. Also, the author of that GConf comparison doesn't seem to understand the problems GConf is attempting to solve which doesn't bode well for it ever displacing GConf.
http://www.redhat.com/archives/fedora-devel-list/2004-July/msg01392.html http://www.redhat.com/archives/fedora-devel-list/2004-August/msg00024.html
http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00039.html
Makes me laugh because I discussed in all those threads :-)
Elektra doesn't want to displace GConf. It actualy can't. GConf provides way more benefits for desktop applications. But.... KDE programs can't access Gnome properties and vice-versa. So here comes Elektra.
Being smaller, simpler, more generic, it fits perfectly as a backend for GConf and a backend for KConfig (KDE's configuration API) at the same time. This way each framework will keep on using its own API and naming conventions, but Gnome apps will be able to access KDE's configuration atoms, and vice-versa. So we can have only one place to store global desktop things like proxy, background, default font, etc. More than that: KDE and Gnome will be able to use their own APIs to access Samba's, X.org's, DHCP, Apache, etc configurations as those softwares were plain KDE or Gnome apps :-)
Avi
On Tue, 28 Mar 2006, Shane Stixrud wrote:
On Tue, 28 Mar 2006, Alan Cox wrote:
Gconf doesn't need gnome. The reverse is true however. The XML format also lets you work with prefences using styles and XML XSLT and the like which is very powerful when working with a large number of systems. Really nobody has scratched the surface of what it can do.
http://www.libelektra.org/GConf has a whole list of reasons why they feel gconf would be a bad choice (at least in its current form) for the system configuration api. A few example it has a lot more library dependencies, was not designed with a global namespace in mind, "GConf storage backend uses XML files, which are big, take long time and system resources to parse or update.", Eletkra has the concepts of "backends" of which gconf is one.
Um, GConf supports several backends as well. Can't argue about the dependencies.. just had a look at rpm -q --requires GConf2 - oh puke. Building another layer on top of that gunk isn't going to help cutting down the dependencies though :)
- Panu -
devel@lists.stg.fedoraproject.org
-
Alan Cox -
Arthur Pemberton -
Avi Alkalay -
Bill Crawford -
Bill Rugolsky Jr. -
Callum Lerwick -
Chris Ricker -
Christian Fredrik Kalager Schaller -
David Zeuthen -
Davide Bolcioni -
Dimi Paun -
Florian La Roche -
Horst H. von Brand -
Jef Spaleta -
Jesse Keating -
Joe Desbonnet -
Joe Orton -
Nicolas Mailhot -
Panu Matilainen -
Paul Jakma -
Pete Zaitcev -
Rahul Sundaram -
Ralf Ertzinger -
Rudi Chiarito -
Sean -
seth vidal -
Shane Stixrud -
Srecko Morovic -
Toshio Kuratomi