Lemme try to explain some background on configuration storage in gnome.
But first, the main complaint in the article is that you can't modify the layout of the fallback mode panel in gnome 3. This is just not true, you can modify them in the UI just like before, only you have to hold down alt when you bring up the menus, etc. This was done because a lot of people accidentally changed their panel around causing problems. I'm sure this change could have been better documented and whatnot, but it is possible.
Once upon a time there was a design decision in Gnome to use so called "instant apply" configuration options, rather than having each config dialog button have "apply" buttons. You can disagree if you want, but this decision drives the design of the configuration framework. Basically, it implies having some kind of service that handles configuration changes that will tell other applications of configuration changes. Thus was born GConf.
The original on-disk format for GConf was an on-disk tree that mirrored the gconf key hierarchy, where each directory had a %gconf.xml file that listed the keys in that directory.
However, it turns out that this is a major performance problem when reading settings. Each such file you open causes two random access seeks on the hard drive. One to read the inode and one to read the data. Hard drive consecutive data read speeds are pretty high, but seeks are very slow (for physical reasons), which was significantly affecting login and app startup speed of gnome.
So, we merged the all the separate files into xml tree files, using one per application. This cut down on seeks a lot and improved performance. (Of course, a negative aspect of this is that the xml files are not very human readable anymore. But the vast majority of readers do not access the text files directly anyway.)
However, even after this gconf reads was a problem for log in performance. We do of course do local caching of gconf data in each process and we preload it in chunks, however during login the gconf daemon was acting as a serialization point for all processes that were starting up. Also, all these xml trees were pretty verbose, so parsing and loading also took some time.
Over the years we increased our knowledge of the problem space, and eventually we came up with a replacement for GConf. It has two parts, one is the API, which lives in glib, called GSettings. Its an abstraction for settings with change notification that has client-side schemas (as opposed to server side schemas like with GConf, another thing we learned). The implementation is pluggable, there is an ini file backend, a win32 registry, and the DConf backend, which is the default for Linux distros.
DConf uses a binary on-disk format that is mmapable and readable without "parsing". I.e. each app maps the config file readonly (sharing this memory), and lookups is done directly in the in-memory mapping without an intermediate parsed copy of the data. The data is stored in an efficient hash-table which allows very fast key lookups with few pagefaults in the file. The actual data is stored using GValue, an immutable binary datatype for recursive types that is in glib. So when a value is returned we don't even duplicate it but just return a wrapped reference to the data in the mmaped file.
Writes to dconf do go through a daemon which handles write serialization and change notification. Communications with the dconf daemon is through dbus, which incidentally has an on-wire binary data format that is a subset of GValue.
So, how does this help us? Well, for one thing we never block during login for reading configuration, as all reading is parallelized. Secondly we don't spend any time parsing files, as the config file, once mapped, is already in a compact "parsed" format. Thirdly, we never waste any memory storing copies of configuration data on the heap.
Now, there are some obvious drawbacks with binary formats. For instance, you need tools to modify them, like the dconf-editor GUI app or "gsettings list-recursively". Secondly, you can't use text based tools like e.g. git, emacs or diff/patch to maintain them.
But, you got to realize that we are not unaware of these problems. We are well aware of them, but we made the conscious decision that the real life problems with the many-text-files approach to configurations (as listed above) outweigh the advantages. Especially considering that most of our users don't need to directly modify the config files.
Also, resurrecting panel items that have accidentally been deleted can be difficult. The "Add to Panel" menu is missing some critical panel items that can (for unfathomable reasons) be removed, such as the "Applications" menu!
I am a little worried though. I have been a Gnome user for the past 10+ years, and this is the first time I don't understand the Gnome vision. I really don't know where you guys are going.
A lot of the rants on the web seem to point that before Linux was trying to copy Windows to lure users, then there was a moment of innovation that created the Linux feel. Lately I have read a lot about Linux trying to imitate Mac.
I don't know if it is true. Right now the vision seems incomplete, and using Gnome hurts. And Hurts bad. I can't seem to use a product that I don't understand.I guess I'll wait a couple of versions to see if I can finally understand Gnome.
The Alt key thing is a problem, though. I never would have found that on my own, even after finally finding out that you have to hold Alt to shut the machine down. I still don't know how to reboot without logging out first (which, I haven't tried, and I don't remember if LightDM has a reboot option either. So yeah, I was CTRL-ALT-F1-ing and rebooting from the command line.)
I mean, it looks very pretty, but how can I recommend this to friends and family when I can't even tell them to "try rebooting it" when there is a problem?
I get the feeling Gnome 3 is going to be awesome. I'm just not sure I'd want to unleash it on non-experts just yet.
I assume (based on your extensive explanation involving cache hits and disk seeks) that you have benchmarked this. How much time is actually saved by this change?
EDIT: Also, http://blogs.gnome.org/desrt/2010/12/19/more-on-dconf-perfor...
To you it's a "major performance problem". To me, it's how I was able to unfuck my panel when I accidentally deleted the NetworkManager applet from it, because it was possible for me to see what was different in a freshly-created (!!) account.
I can't seem to find out how to add new entries in dconf-editor, nor can I figure out how to add applets to the panels (I _need_ bubblemon)...
I have been using GNOME since 1.something.
Regarding the one-big-file: the time saving is nice, but that speed gain is kind of defeated when logging in hangs for 15 seconds (perhaps trying to find out why X doesn't do 3D on my graphics card, or something else?) - and the end result being _slower_ login in GNOME 3 compared to GNOME 2.
I remember seeing KDE for the very first time when it was in beta and saying, "Wow!"
For a while I'd have a horrible feeling of disappointment when GNOME and KDE would come out with new versions because each would seem to be to buggier and less usable than the last. Sometime around 2005 or so I gave up. It became less of a PITA to configure a Windows machine to make a decent workstation than it to use Linux. I still use Linux on the server, but almost never as a desktop.
I used Linux first in 1993, and back then it was leaps and bounds ahead of Windows in every way. It wasn't until 2000 that Windows brought brought out a stable operating system based on a good foundation that was actually competitive with Linux. Windows has grown a lot since then, and Linux has either been standing still (or almost, on the server) and going backwards (on the desktop). It's a tragedy.