Linked by Thom Holwerda on Tue 18th Jan 2011 22:18 UTC, submitted by alinandrei
Ubuntu, Kubuntu, Xubuntu De kogel is door de kerk. After years of focussing entirely on Gtk+ and GNOME, Ubuntu will finally start evaluating Qt applications for inclusion in the defaukt Ubuntu installation. Mark Shuttleworth announced the policy change on his blog today.
Permalink for comment 459074
To read all comments associated with this story, please click here.
Can we discuss something useful?Z
by sorpigal on Wed 19th Jan 2011 12:10 UTC
Member since:

The comments here are really all over the place and waxing into hysteria and then waning into irrelevance. Can we discuss something useful?

What Shuttleworth brings up is a good point and an interesting technical challenge that's worth solving. A unified config API is something which has been of great utility in Windows from an application developer point of view, and remember that more developers==more apps==better for users, and it has long been my thought that Linux could use something similar.

Other attempts have been made to create the be-all and end-all of configuration systems on Linux, but they have all been misguided as far as I can tell. gconf and systems like it fail because they also effectively unify config storage, which is a hot button issue. No one wants another Windows Registry! And yet the gconf devs only reluctantly moved away from storing data in a big binary blob. Things like Project Elektra (formerly known as linuxregistry) have attempted to create a unified API and a pluggable storage mechanism, to an extent, but the proposal for elektra was that all software (including and especially daemons) be rewritten to use it, throwing away the native config file format. This was a non-starter for most projects, and rightly so.

We don't need a unified storage system. What I mean is that there's very little incentive for apache and samba to store settings the same way as each other, much less the same way as emacs and vim. Having a separate config format for each daemon is a reality only a fool would attempt to combat at this time. However, when it comes to regular desktop apps our options are far less limited. Most user apps don't require anything fancy config-wise, and most developers of user apps aren't attached to any specific config storage system. Unifying most user apps would certainly be possible.

What I really don't want to see, however, is another gconf. It's not sufficient to have a massive inscrutable database which requires special tools to access and process--this is something elektra got right with its FS back end. Some concepts from gconf, and indeed from Windows Registry, are useful to take in to account: Configuration policy set by the system, global defaults, user settings, and how those are combined into a final set of settings. Any system which fails to keep in mind the corporate-lock-down scenario is doomed to eventual inadequacy.

What we need is a simple and stable API that app authors can target and easily understand. It's got to be good for simple cases like "I need to store a flag" or "I need to store some key/value pairs" to more complex cases like "I need to know whether this setting is available to this user" or "I need to store a complex data structure." Ideally the system will impose no overhead, be able to transparently expose settings to remote systems, not enforce a single storage mechanism, have no concurrency issues, be resilient in the face of crashes and unexpected failures, allow applications to subject themselves to policy control, and so simple to use that every developer will want to adopt it.

I see that there are not many docs on dconf. I don't want to dismiss it out of hand due to my own ignorance, but what I have seen does not suggest that it is the best solution to simplifying user application settings storage and access. It certainly seems insufficiently neutral to appease all developers of KDE, Enlightenment, and so forth.

So, what is the correct design for the perfect desktop configuration system? You tell me.

Reply Score: 4