User: Password:
Subscribe / Log in / New account

A look at GNOME Shell

A look at GNOME Shell

Posted Jun 11, 2010 2:29 UTC (Fri) by k8to (subscriber, #15413)
In reply to: A look at GNOME Shell by rahulsundaram
Parent article: A look at GNOME Shell

Wow, reading this post, it soudns even worse.

Dconf using a binary format... (registry sickness deepens)

(Log in to post comments)

A look at GNOME Shell

Posted Jun 11, 2010 2:43 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

It is actually a key based configuration. The binary format is merely a method to avoid slow reads.

A look at GNOME Shell

Posted Jun 11, 2010 2:55 UTC (Fri) by k8to (subscriber, #15413) [Link]

I read that link. It caused my comment.

Let me introduce you to another key-based configuration with binary format:

They, too, introduced it for performance rationales. Funny that the performance issues are drastically less than that point in time, 17 years ago.

A look at GNOME Shell

Posted Jun 11, 2010 3:01 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

It is well known that binary formats have the advantage of better performance regardless of whether Microsoft is using it or not. D-Bus has benefited from one and that is used throughout the freedesktop stack. ksycoca in KDE does something very similar as well. Get over it.

A look at GNOME Shell

Posted Jun 11, 2010 3:18 UTC (Fri) by k8to (subscriber, #15413) [Link]

And it is well known that binary formats have disadvantages for automation, recovery, and investigation. Conf keys are not a heavyweight activity, so playing up performance at the expense of these other conscerns for this domain is just foolish.

The article I linked was notable not because it is a Microsoft document, but it is a Microsoft document communicating how to try to recover from a corruption issue common enough to require a knowledge base entry. This should make the problems with binary format config hives understandable to everyone.

A look at GNOME Shell

Posted Jun 11, 2010 3:56 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

Performance has certainly been a concern with Gconf. We will see how it goes. The developers certainly think it is a valid trade off and you are free to opinionate that it is foolish but since they are doing the work, that is what ultimately counts.

A look at GNOME Shell

Posted Jun 11, 2010 7:45 UTC (Fri) by k8to (subscriber, #15413) [Link]

No, ultimately what counts is whether it works, and works well.

Certainly, I'm not going to make it work well. But those who will not learn the lessons of history won't either.

A look at GNOME Shell

Posted Jun 11, 2010 9:56 UTC (Fri) by dgm (subscriber, #49227) [Link]

You forgot to explain what "works well" means. For dconf's developers it seems to be "runs fast", while "works realiably" seems to be yours.

A look at GNOME Shell

Posted Jun 11, 2010 12:16 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

We have no scarcity of opinions. We do certainly have a problem of getting people to do the work involved unfortunately. If it doesn't work well, it will fail on its own terms. I rather reserve judgement till that point.

A look at GNOME Shell

Posted Jun 11, 2010 14:12 UTC (Fri) by jond (subscriber, #37669) [Link]

The thing is, sticking with our current non-binary system requires no work.

A look at GNOME Shell

Posted Jun 11, 2010 15:36 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

No work involved for maintainers or users doesn't make a system ideal if the current characteristics are not right for the next major version of a desktop environment. GNOME has been thinking about a replacement for Gconf for quite sometime. With the opportunity now, they have. One could argue, the previous system was perfect but that isn't reality.

A look at GNOME Shell

Posted Jun 11, 2010 9:49 UTC (Fri) by farnz (subscriber, #17727) [Link]

That link raises concerns for me that ksyscoca does not. In particular, if I get a random bitflip in my ksyscoca database that renders it unusable, I can recover easily - I just erase the ksyscoca database, and let it rebuild from the configuration files. Similarly, if I end up with a corrupt configuration that I cannot fix through the GUI, I can recover by hand-editing the configuration files, or deleting the bad configuration file, logging out and back in, and reconfiguring that component through the GUI.

With the exception of recovering a corrupt ksyscoca database (which can be detected programmatically and handled without user intervention), these are operations at the level of smart geek, not ordinary user; however, as someone who fixes "computer problems" for ordinary users, being able to say "I've kept most of your personal settings, but you'll need to reset the wallpaper/check your bookmarks/whatever bit was damaged" is a much nicer position than I'm in with Windows systems, where all I can say is "you've lost all your settings."

A look at GNOME Shell

Posted Jun 11, 2010 12:23 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

Here are more details

You should be able to rebuild your schemas if necessary.

A look at GNOME Shell

Posted Jun 11, 2010 13:13 UTC (Fri) by farnz (subscriber, #17727) [Link]

That doesn't reassure me any, I'm afraid. ksyscoca takes a bunch of text files under ${HOME}/.kde, and parses them into an efficient binary blob form that lives in /var/tmp. The KDE API for handling configurations keeps the binary blob and the text files in sync; if I edit the text files outside of the KDE API, I've invalidated the ksyscoca binary blob, and need to recreate it. KDE will do this automatically when I log in (based on mtimes, I assume), or I can blow away the binary blob, and still keep my settings unchanged.

The link you've given suggests that if I rebuilt my schemas, I'd lose my custom settings. That's a distinct retrograde step from ksyscoca, where if I wipe out my binary blob, I can rebuild with my existing settings from the text files; further, I can edit my settings with tools such as "vi" (useful in a broken-the-world scenario), blow away the binary blob, and have KDE rebuild the binary blob for me.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds