26 ms·
Good article but I think everyone at Microsoft knows the registry was a mistake at this point. It was designed in 1991 after all. Microsoft does seem to be sl
by SamAtt 17y ago
Good article but I think everyone at Microsoft knows the registry was a mistake at this point. It was designed in 1991 after all.
Microsoft does seem to be slowly moving away from it (see point #9). But outright replacing it just isn't an option.
Do a cost/benefit analysis and you realize that it would be very expensive to replace it (while maintaining backwards compatibility) and 99.9% of people don't care one way or the other.
- old-gregg 17y agoThat didn't stop Gnome from re-inventing it with gconf :-( Ughh... Now rgrep /etc for a config setting is broken, apps leave garbage sitting in there upon uninstall and you need a stupid GUI tool to deal with it.
- jpablo 17y agoWhat's bad about giving programmers a standard API to store config settings so they are in a central place and can be tweaked by administrators and users using gui tools (for other people you can still grep ~\.gconf or use they command line tools). I don't think the Windows Registry is a bad idea by itself, it's just a poor implementation and very badly organized.
- old-gregg 17y agoNothing's wrong with it. Make it a simple text file and place it in /etc where it's supposed to be anyway. Don't make users chase different config locations for different programs. UNIX already has a standard for storing configuration. It is simple, text-based, scriptable and standardized. And there is no need for "standard API" here. Its too late. GConf doesn't cover 99% of whats on a typical Ubuntu system, so why did they invent this "standard" for 1% of all system settings? Why fragment the system?
- xpaulbettsx 17y agoBecause Registry / gconf et. al. provide cheap notifications of when a specific key changes. This is the reason that a registry-type solution is useful, as well as helps performance. Your solution means that every app interested in a setting has to put a file change notification on the conf file, then reparse the entire thing and diff it to see what changed.
- randallsquared 17y agoSo expose that in a library. Most conf files are one of a few common formats, and it shouldn't really be a problem to reparse on change. The client app wouldn't have to know anything about the file, even, just get settings back in some standard format. That library seems like a weekend project for someone, with format plugins and other goodies to follow.
- bad_user 17y ago> Most conf files are one of a few common formats That's not my experience.
- micampe 17y agothat library is gconf, you just need to implement a different backend by writing one of those format plugins you mentioned.
- randallsquared 17y agoOh. I had the impression that gconf only dealt with Gnome's internal "registry".
- Tuna-Fish 17y agoUnless you are logged in as root, most of the stuff in gconf should not be in /etc. Actually, even then they'd be better in /root/.<whatever>. I do dislike grouping unrelated application settings into ~/.gconf -- before, if you screwed up a setting you could always just rm -rf .<whatever>, without losing anything unrelated.
- skulgnome 17y agoNo. The root user's configuration and the systemwide configuration are distinct. /root has the former, and /etc has the latter.
- wfaulk 17y agoI do dislike grouping unrelated application settings into ~/.gconf -- before, if you screwed up a setting you could always just rm -rf .<whatever>, without losing anything unrelated. Oh, God yes. It's awful. There are severe usability problems with lumping everything together. (Of course, this is outside the issue of the original post.) In addition, if GConf is the One True Way to store Gnome settings, why do I have ~/.gconf, ~/.gconfd, ~/.gnome, ~/.gnome-rdp.db, ~/.gnome2, ~/.gnome2-private, ~/.gpilotd, ~/.gpilotd.pid, and ~/.gtk-bookmarks?
- viraptor 17y agoThere was never a standard for user configs (unless you mean .files all over you $HOME). GConf provides some schema and metadata that might prevent errors when modifying stuff yourself. I think it covers quite a lot actually... do you have any examples of what it cannot do? In my experience configs are usually just key=value lists (sometimes with sections). That's exactly what GConf does nicely.
- old-gregg 17y agoExamples? Well in my case nothing is stored in Gconf: vim, irssi, apache, postfix, firefox, skype, sound settings, wifi etc So what's the point of this "standard API" then? Just to make life harder for KDE/XFCE folks to run GTK apps that were written by unfortunate souls who use gconf and suddenly packaged with gconf-daemon as a dependency?
- viraptor 17y agoI meant user apps. Servers don't need unified storage that much and they don't belong to user accounts really. Ok, so skipping server stuff (and remembering that the question is "examples of what it cannot do"): Skype is not really a part of the linux environment... they do what they want and they would probably prefer to just port the windows solution, but I don't see anything they could not store in gconf. Sound settings - gnome-volume-control uses it, same with gnome-sound-recorder, gstreamer too - sound server itself is system-wide, so it doesn't have place in gconf. Vim uses scripts, same as Irssi, so fair enough it cannot be done Firefox could use gconf - it just needs a key=value set. Apache, postfix, wifi, sound daemons - those are servers/system-wide providers... From the project site: "GConf is a system for storing application preferences. It is intended for user preferences; not configuration of something like Apache, or arbitrary data storage." But I think I lost the main point somewhere - here it is: of course you cannot do everything in gconf (scripts), but most of the app preferences fit this model perfectly - and many of them do use gconf - just check the list of apps using it on your system.
- FooBarWidget 17y agoExamples? Uh, pretty much the entire Gnome desktop? Pretty much all Gnome applications? Gedit, Nautilus, Gnome Terminal, Metacity, Compiz? Yeah so GConf isn't a standard for the entire system. So what, does it need to? GConf has never promoted itself as a system-wide standard, just as a standard for Gnome. The point? As someone else said, GConf provides change notifications, something which is an integral part of the Gnome UI experience: instant-apply for all settings. If you change a window manager hotkey in a config tool, Metacity/Compiz will immediately notice the change. If you change some Gedit setting in a different tool then Gedit will immediately pick it up. Firefox doesn't use GConf because they already have their own cross-platform config storage system, and they suffer for it: if I change the fonts (font settings are stored in GConf) then every GTK app immediately picks up the change, but not Firefox - I have to restart it. You said GConf is a reinvention of the registry, and for some reason you apply a negative label on that. None of the technical reasons on why the registry sucks, as mentioned in the article, is true for GConf: - GConf does not store settings in a big monolithic file that tries to reimplement the filesystem. It stores each config directory as a separate XML file on the regular filesystem. These XML files are parseable and editable with standard XML tools, which are plentiful. - GConf has pluggable backends. The XML one is just the default one. You can write a backend that stores settings in an SQlite database, a MySQL database, or even the Windows registry, or maybe as files in /etc if that's what you really want. - GConf is completely open. There are no weird file format glitches. The default XML files are portable between machine architectures. Basically the only reason you hate GConf is because it looks like the registry, and because the registry is bad, everything that looks like it must automatically be bad regardless of their actual design and implementation merits, right? What is this, 2002? I thought people were finally over this nonsense but apparently not.
- bad_user 17y agoThose simple text files you mention all have a different syntax. And I've never seen a usable Samba or Apache configuration GUI ... wonder why that is. You're also talking about /etc ... which is go-rw, and user configuration files are all over $HOME.
- rwmj 17y agoYou might want to take a look at Augeas (http://augeas.net/ http://augeas.net/) which offers standard "lenses" (ie. parsing filters) for pretty much all Linux /etc files.
- jpablo 17y agoThis is user settings, so it shouldn't go in /etc. But some where in ~\ And then gconf is text-based and scriptable and standarized (xml)
- kelnos 17y ago"UNIX already has a standard for storing configuration. It is simple, text-based, scriptable and standardized." False. Go ahead and cat a few files in /etc/: nsswitch.conf: key/value, separated by colon. Lists of values are space-separated fstab: per-line record-based, 6 space-separated fields passwd: per-line record-based, 7 colon-separated fields fuse.conf: key/value, separated by equals sign hdparm.conf: hierarchical, using curly braces; inside that, key/value, separated by equals sign What "standard" are you referring to?
- FooBarWidget 17y agoPeople who think /etc is a standard don't know what they're talking about. Almost every app has its own config file format; some of them just superficially look like each other but really aren't. I can give more examples: - Apache: hierarchical key/value, separated by space. Hierarchy can be started and ended with XML-like-but-not-quite syntax, where the hierarchy container itself can contain a value. - Nginx: hierarchical key/value, separated by space. Hierarchies can be started and ended with brackets. - screenrc: key and one or multiple values, separated by space. - nanorc: key/value, separated by space. - /etc/network/*: shell scripts. - inittab: ??? no idea what the formal syntax is. People who complain about GConf with the reason that "/etc is superior" usually have no clue how things really work, yet they still behave like they're experts.
- rbanffy 17y agoAnd why on Earth would someone think he has the One True Way of storing configuration in a file? I see nothing wrong in each program storing configuration data in the most convenient way for them. For Gnome applications there could be standard APIs. And, as a bonus, they should store the configuration data in plain text files according to whatever format Gnome finds convenient, but not making us use specific tools to edit it, much like the Founding Fathers of Unix didn't tie config files to ed. Which is how GConf will look in 10 years.
- harshavr 17y agoSince you can use gconftool shell command to get & set key values, it seems consistent with the unix philosophy. It is actually easier to use in a script than to parse a text file. For tree level operations, one can use the standard directory commmands like mv, cp inside the ~/.gconf directory. gconf-edit is a tool you use only if you want to. One could actually write a simple emacs mode for doing the same thing.
- Sidnicious 17y agoI really like OS X's solution — files stored in appropriate places in the file system which can be either human-readable or a format which is easily converted to human-readable, and there's built-in support for inheritance (user-host inherits from user inherits from system inherits from defaults).
- Zak 17y agogconf is a clone of the regedit GUI, but the storage mechanism is not. The article was entirely focused on the storage mechanism. The .gconf directory structure is simply stored in the filesystem. It's not a replacement for /etc, but for the dot files individual apps would otherwise use for per-user configuration. Configuration data is just XML, and can be grepped, edited and deleted from the filesystem just as any other dot files can. The deep directory structures and XML aren't quite as friendly to traditional Unix tools as are traditional dot files, but those tools remain entirely usable, while apps get a shared API for configuration.
- sern 17y agoAre you sure? Vista added something called Boot Configuration Data to replace Boot.ini. Not somewhere they needed backwards compatibility. At the very least, they could have designed/adopted a sane binary database format. But no, instead they decided to use their precious registry hive format.