Reading this thread makes me pretty sad. Usually there are people on hacker news that at least know the background, and generally there is a measure of respect

Reading this thread makes me pretty sad. Usually there are people on hacker news that at least know the background, and generally there is a measure of respect that other people might actually know something about what they work on. The Gnome developers (which includes me) have more than ten years of experience working on unix and developing a desktop for it. Please don't assume we're making decisions because we're stupid, we might actually have reasons to do what we do. 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.