To view parent comment, click here.
To read all comments associated with this story, please click here.
ESR should lay down the crack pipe, and you with him.
you two obviously haven't been working for the past 6 or 7 years to optimize the startup time of a complex system, with multiple moving parts, all reading the configuration from a centralized source (necessary so that you get notifications when anything changes, instead of using a ton of file system notifications and run through the kernel limits).
using text for the database is stupid, wasteful, and totally inefficient.
text for configuration is useful if you have to read it once, and the only write operation happens as the user opens the file with a text editor; imagine if we said that Gnome users had to stop the session to change the settings, and that there would be no settings UI whatsoever.
oh, well, this is ESR, who doesn't believe in allocating memory, and left a static array of 1024 multi-kilobyte structures in GPSD:
http://gypsy.freedesktop.org/why-not-gpsd.html
No, but for more than 15 years. Actually, not at all. I don't spend much time at optimizing the startup since it's a waste of time, unless it's ungodly slow but that's usually not the case and when it is it's never due to the use of text configuration files..Startup, as the name implies, happens very seldom and it's not worth spending too much time on. Run-time performance is what counts and the configuration format has very little to do with that.
Wrong, wrong and wrong. What's stupid is using a configuration format that can not easily be repaired and managed by humans, what's wasteful is spending time on optimizing things that has little to no impact and it's inefficient to spend time on solving a problem that does not need solving.
You know, I could swear that this has worked perfectly fine up until now in both GNOME and KDE. I distinctly remember there being UI's for settings in pretty much all GNOME and KDE apps.
OK, so you check to see if the text file has changed (timestamp should be sufficient, filesize if you really want to get fancy) on startup. If it has, you parse it, and convert it to the hidden binary blob. If it hasn't, you just use the binary blob.
There, you get the speed benefit of the binary blob, with the ease of configuration of the text file.
Alternately, if you don't want the overhead of checking for the binary blob, create a "configuration compiler" that you manually run whenever you change the configuration.
So, the 'binary blob' comes from dconf, which provides an implementation of Glib's settings API. If you don't like it, there's nothing stopping anyone from writing a replacement that uses text files - in theory, it wouldn't be all that hard, as none of the Gnome code should be using dconf directly...





Member since:
2006-03-13
It's important to understand ESR's objections to Gnome 3. You can read them here:
http://esr.ibiblio.org/?p=3822
His biggest objection to Gnome is this: "While you can add applets to the fake GNOME panel, you cannot remove them or shuffle them around. Eventually, by making a fresh account, taking checksums of its dotfiles, adding an applet, and taking checksums again, I found out that the new panel configuration lives in a file called .config/dconf/user that is an opaque binary blob."
ESR is right, using binary blobs for configuration is a major UNIX sin. As he writes: "burying my configuration inside an opaque binary blob – that is unforgivably stupid and bad engineering. How did forty years of Unix heritage comes to this?"
I haven't been able to try the new Gnome out out, as it doesn't like Virtualbox.