64

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?

Braiam
  • 67,791
  • 32
  • 179
  • 269
nkint
  • 2,025

1 Answers1

68

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.

Oli
  • 293,335
  • 1
    very clear answer. reading your answer (expecially last 3 point) i think that gconf even if slower is better.. – nkint Apr 11 '11 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. – James Henstridge Apr 11 '11 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 '11 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. – Jo-Erlend Schinstad Nov 20 '11 at 08:06
  • ??? if I open both gconf-editor and dconf-editor then the structure and keys differ greatly. So I do not believe it is the same system which differ only in encoding (binary X XML). – kapetr Mar 12 '13 at 09:16
  • 1
    @Jo-ErlendSchinstad something going wrong always has the opportunity to screw up VCS's control files too. – Ruslan May 14 '17 at 05:44
  • @Ruslan Better back those up too... really though, you have options no matter how seriously you take this - a discount thumb drive, RAID, remote backups and so on. If it would ease your minds any, the blob doesn't have to be a "direct translation" but it will always have a translation, right? I can see dconf-export as well as built-in utilities, dconf dump /.../, e.g. dconf dump / to barf to stdout, corresponding to dconf load and so on. Then make, daemonize, whatever you're comfortable with. Is that any help? – John P Feb 20 '18 at 03:58
  • Yes, but does dconf need a service whereas gconf is only a static file read directly by applications? Why does no-one ever mention these significant differences? – NeilG Jul 20 '23 at 22:28