Hacker News new | comments | show | ask | jobs | submit login

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.

Anecdata: I've supported Ubuntu desktops for non-technical users, and they do indeed seem to have an amazing ability to accidentally re-arrange panel items, even with "Lock items" ticked. I'm entirely in favour of making it more difficult -- although I probably wouldn't have figured out holding down "alt" by myself, but I would hopefully have found it with some googling.

Rearranging panel items is surprising clunky compared to Mac OS X.

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 appreciate the time you took to respond. And I just want to say, that in my case, I am willing to stay with Gnome and see what you guys come up with. Right now, I feel like this is an alpha release, and it will get better, and that the vision will be realized.

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.

Thanks for the information. Really.

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.

It seems to me like you've fallen in a well and are trying to get out by digging it deeper.

Thank you for doing this. I, for one, am willing to use dconf-editor or gsettings during the once-in-a-blue-moon occasions where I need to modify the binary blob if it results in faster startup times for login and apps.

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?

> However, it turns out that [an on-disk tree] is a major performance problem when reading settings

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.

Thanks for the ALT-key hint. I hadn't found that piece of information anywhere else, so I was trying to edit the two panels using dconf-editor. I got them placed in each corner on the right side (my screen is much wider than it is tall), but every time I log in they jump to being vertically centered...

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.

If configuration writes are serialized through a daemon, why not use the same daemon for configuration reads? The daemon could parse the text-based configuration files once and then publish the parsed settings using shared memory (protected by a read/write lock, since reads will outnumber writes)? The daemon could update the published settings in shared memory and slowly write them out to disk.

Thanks for explaining all this.

Thank you for your hard work. GNOME 3 is amazing - its very non-intrusive, responsive and very functional. I've never been happier with a desktop.

Smart or not, the horrible truth is that every version of GNOME and KDE seems to be more unusable than the one before.

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.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact