David Zeuthen <david(a)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
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,
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
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
- 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
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
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
That some people don't know how to do it right doesn't mean it is the wrong
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.
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
Pray tell, where would the user settings come from? Not from a
Yes, display configuration is also per-user although the
brain 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
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
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
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
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513