I've read a lot of discussion about a new Ubuntu configuration tool: gconf is replaced by dconf.

Why is this change being made? Why is there so much debate about it? Is it too difficult to create a gconf2dconf migration tool?


1 Answer 1


gconf typically uses an XML backend, while dconf uses its own binary blob. From that change alone you can draw up some points:

  • Binary read access is far faster than parsing XML
  • According to dconf's design section, a Gnome login consists of thousands of read operations and only a few writes. To gconf that's thousands of stats, thousands of reads and thousands of parsings. dconf's binary blob would blitz through those without bogging the system down with umpteen thousand IOPs.
  • XML is more portable
  • XML is largely human -readable and -editable.
  • A file-based system can be separated and portioned without much hassle
  • Corruption of a monolith binary file could mean the whole thing dies. Single file corruption only hurts that segment in gconf.

A lot of the arguments are those levelled for and against the Windows registry.

As I understand it, the interface onto this settings back-end would be the same as gconf: through GSettings. This would allow distributions and users to chose one and switch out if they needed to.

  • 1
    very clear answer. reading your answer (expecially last 3 point) i think that gconf even if slower is better..
    – nkint
    Apr 11, 2011 at 14:05
  • 22
    One other big point of difference is that reading settings from dconf is done entirely in process, with IPC only occurring for writes and change notification. In contrast, almost every GConf operation involves IPC. You may also be overstating the benefits of GConf using XML too: the only supported method of accessing the GConf database is via the GConf API, and directly editing the XML files while gconfd is running may have unexpected results. Apr 11, 2011 at 14:15
  • 2
    I think the main advantage of using something text-based is the ability to rescue parts of it with any text editor when the file gets partially corrupted (but I guess in theory it's possible to write a tool that can rescue parts of the binary blobs too?).
    – JanC
    Apr 22, 2011 at 18:39
  • 3
    I think the best way to rescue would be to put ~/.config under version control, which would enable you to simply rollback if anything went wrong. That would fix any intentional config changes with unforeseen side effects too. Nov 20, 2011 at 8:06
  • 1
    @Jo-ErlendSchinstad something going wrong always has the opportunity to screw up VCS's control files too.
    – Ruslan
    May 14, 2017 at 5:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .