The registry's implementation is bad, sure. However, a global key/value store is extremely useful. I changed the default background color in Windows from 'White' to 'Light Gray,' and it works for almost every application I use. Visual Studio, Explorer, even some webpages! For years, I turned the brightness of my monitor down, but that severely hinders readability of some color schemes.
How would global shared settings look without a registry? Like Unix configuration files. This is a step backwards, as there is no unified way to read Unix configurations. Some things are stored in environment variables, some things are stored in XML files, some things are represented as special files, and some things are stored in INI-style files. Something like window color would be handled by the display manager, but other configuration settings would need to be hunted down at runtime.
What's really better, "read system.window.background.default_color.[rgb] as ints," or "parse /etc/x/conf/x.conf as an .ini file, look for the variable background_color. It is stored in the format (r,g,b). If it is not present, the default is (255,255,255)."?
You could create a library to read the setting, and everyone could just use the library.
I like the Unix way better myself, as it's more about building up functionality through composition, rather than setting out to create grand unified architecture. Speaking (possibly too) generally, I find large architectures tend to be harder to fix.
As opposed to Mac OS X, where many apps can't agree on which key binding to use for switching tabs to the left or right? Alt+Cmd+Left/Right in TextMate and Firefox, Alt+Left/Right in Adium and iTerm, Apple's own apps use Alt+[/]. Or Windows where there are a gazillion of widget sets that only happen to look like each other? MFC, WinForms, VCL, Fox, FLTK, Tk, WTL, etc. not to mention that almost every commercial app thinks it's cool to use custom controls that don't look or behave like the rest of the system.
And these are supposed to be serious desktop OSes?
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.
What'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.
Nothing'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?
People 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.
And 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.
Since 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.
GConf files aren't binary; they're XML. It may not be the greatest format, but it's editable and rgrep-able, and gconf-editor documents many of the keys. Sometimes it's good to declare One True way of doing things just so you know what to expect, and if GConf really doesn't work for your app, you don't have to use it; there are still plenty of GNOME config files outside .gconf/.
I have played with Gnome config files a couple times and never quite appreciated their organization. With all due respect (I never contributed a single line of code to Gnome) I think that keeping config in lots of human-friendly formats such as yaml is a better solution than grouping stuff in XML files.
It's not nearly as bad a solution than the Windows Registry, but it's not perfect either and has some good chances it's not a step in the right direction.
"And why on Earth would someone think he has the One True Way of storing configuration in a file?"
There is no One True Way. Only a bunch of good ways, a bunch of bad ways, and a bunch of sorta-ok ways. Just because there isn't one amazing way that is obviously the best, it doesn't mean that the alternative is for everyone to use different, incompatible formats.
"I see nothing wrong in each program storing configuration data in the most convenient way for them."
Clearly you've never had to administer systems before. Or, if you have, you're so used to it at this point, you don't remember what it was like when you were starting.
I would much prefer to only have to understand and remember a single config file format and save my time and effort for things that actually matter.
But yes, I'm a hypocrite: I designed and implemented Xfce 4.6's configuration storage system... yet another incompatible format.
And who would that "someone" be? I'm not advocating GConf for becoming the standard config storage mechanism for Unix. I'm simply defending it from people who think that it sucks for the wrong reasons.
And as someone else mentioned, the files are plain XML that you can edit with a text editor. No special tools.
The standard of each application doing things in a slightly different way, and of tolerating a bit of legacy cruft on the side. This is a far cry from the Windows registry hell; even gconf is a far cry from Winders registry hell.
IMO the "standard" of /etc is an explicit non-standard. It consists of free-form text and a filesystem - and all the tools that existing for dealing with those things.
Unless 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.
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.
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?
Because 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.
So 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.
There 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.
Examples? 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?
Examples? 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.
"Entire gnome desktop"? WTF is that? Everybody is using a mix of Qt/GTK apps, and thanks to "just-for-gnome" turds like gconf nothing gets along and you have to google and dance around several incompatible configuration GUIs.
Pardon me, but "instant apply" feature is not enough to excuse for this mess: yeah, I change something in Gconf and maybe 20% of apps pick up my change instantly. A whopping 20%, but INSTANTLY, was that the goal?
They should have ALL kept using standard /etc + ~/.xxrc files or came to an agreement to use something truly global, so I could enjoy the same font rendering or a freaking window colors in Skype and Pidgin. I can live without instant config changes but at least I could have grepped "color" and "window" appearing on the same line somewhere in /etc and in ~/.gtk or ~/.kde.
Tools like GConf are destroying one of the greatest UNIX strengths: scriptability. I keep versions of config files for selected software under git and simply push it to /etc when I need to quickly set up a new machine. Nobody needs freaking "pluggable back-ends" because everybody needs to be able to instantly backup/restore selected applications configuration in a standard way
And is it really worth it to run a freaking daemon so you can see your config changes instantly take effect?
Also, your comment has "XML" in it. Are you sure? Seriously? Why not PDF? It's about as good as XML for storing key=value pairs, there are lots of tools developed for it too! And just as useles for sed/awk/grep.
This disease of bloating up simple things into monstrosities based on "pluggable architectures" must be contagious: some infected gnome devs must have sat at the same table with GRUB-2 folks, so now we've lost a great bootloader.
> Everybody is using a mix of Qt/GTK apps, and thanks to "just-for-gnome" turds like gconf nothing gets along and you have to google and dance around several incompatible configuration GUIs.
So now we have, Gnome-specific config storage, KDE-specific config storage, and the rest all uses its own config storage. So now we have at least two classes of apps that use their own standard config storage. Getting rid of GConf would mean all of those apps would use their own config storage, creating even more fragmentation. That would be better, how?
> Pardon me, but "instant apply" feature is not enough to excuse for this mess: yeah, I change something in Gconf and maybe 20% of apps pick up my change instantly. A whopping 20%, but INSTANTLY, was that the goal?
No idea where you pulled the 20% number from. It's always 100% in my experience with the exception of Firefox and font settings.
> They should have ALL kept using standard /etc
/etc is not a standard. Did you ignore what everybody else has been saying?
> + ~/.xxrc files
Oh like ~/.gconf?
> or came to an agreement to use something truly global, so I could enjoy the same font rendering or a freaking window colors in Skype and Pidgin. I can live without instant config changes but at least I could have grepped "color" and "window" appearing on the same line somewhere in /etc and in ~/.gtk or ~/.kde.
Agreed, but this problem has got nothing to do with GConf. Getting rid of the GConf you so hate will not solve this very problem.
> Tools like GConf are destroying one of the greatest UNIX strengths: scriptability.
gconf-tool. Completely scriptable. Enjoy.
> I keep versions of config files for selected software under git and simply push it to /etc when I need to quickly set up a new machine.
Put ~/.gconf in git. Enjoy.
> Nobody needs freaking "pluggable back-ends" because everybody needs to be able to instantly backup/restore selected applications configuration in a standard way
Yeah, if only those stupid GConf files are backup-able with standard tools like 'cp' or 'tar'! Oh wait... they are!
> And is it really worth it to run a freaking daemon so you can see your config changes instantly take effect?
It is really worth requiring an entire windowing system and fancy graphics just so one can see images in a web browser? We should just stick with telnet dammit!
Yes. Why not run a daemon? It eats maybe a few hundred KB of private RSS. Even an old desktop system by today's standard has 256 MB of RAM. The daemon also improves startup performance by caching a small set of active configuration settings in memory instead of having to constantly load them from disk, something which is not possible if every app parses the config files.
> Why not PDF?
Why PDF? I'll tell you why not PDF, because it's not a good format for storing config, what's why! You said there are lots of tools for editing PDF - but none of them are usable for editing key-value pairs. As opposed to XML tools. If the XML file hard to read? Use xmllint to reformat or to indent it. Edit with a standard text editor. grep, sed, awk, all work, I have no idea what you're talking about.
No, I think your fear for 2010 technology and your tendency to stick with 1970s stuff is more of a disease.
So now we have, Gnome-specific config storage, KDE-specific config storage, and the rest all uses its own config storage.
No. If Gnome-specific and KDE-specific config did not exist, we all would have standard ini-style config files sitting in /etc (for system/root) and in ~/.gnome and ~/.kde respectively with each program owning a file named after itself.
Also, the biggest problem with windows registry isn't its internal structure: users don't care about that. The issue with registry is that it grows over time and never shrinks due to buggy and forgotten programs that leave junk in there. That's #1 reason why people complain about their computers getting slower. GConf happily inherits this fatal flaw because find ~/.gconf/ -name "program" won't find anything.
Again: gconf-tool is an example of a non-standard little turd that I was referring to when expressed my annoyance with managing multiple configuration systems. And how is placing ~/.gconf under git helps me to quickly restore configuration for selected apps? Have you looked inside of .gconf? Have you seen wifi.conf file in there? Those who have would no doubt pick /etc. One more time: gconf is not find/awk/grep/sed friendly, hence it is a maintenance nightmare.
Yes. Why not run a daemon? It eats maybe a few hundred KB of private RSS.
How typical for a 2010 technologist: "I want this little tiny toy feature which will eat only a few insignificant hundred KB...". You know what? Users have hundreds of little tiny little needs that would enjoy running all time time. I can keep naming things forever that a computer is capable of doing, and if you multiply those hundreds by your "few hundred KB" very quickly you'll end up with something like Vista: functional yet barely capable of running itself. Moreover, are you sure gconfd eats hundreds of K? Care to look again?
Sending configuration change notifications is NOT a significant feature to have its own daemon. Even Windows is smart enough to run a single svchost.exe service that groups tens of little background features like that into a single process.
No, I think your fear for 2010 technology and your tendency to stick with 1970s stuff is more of a disease.
The industry seems to be voting my way: it is simple 1970s pieces of Linux tech that dominate competition, yes - those that read their config from ini files in /etc. And your 2010 "pluggable technology" is still waiting for a year of Linux desktop.
> And how is placing ~/.gconf under git helps me to quickly restore configuration for selected apps? Have you looked inside of .gconf?
Yes - it contains the hierarchy mapped to directories. In my case `.gconf` contains directories `apps`, `desktop`, `system`. Then `apps` contains a subdirectory for every application using gconf - for example `ekiga`. You can revert the chosen directory there to revert the version for a single application. I honestly don't know what problems are you seeing.
> Have you seen wifi.conf file in there?
No, I don't have it. All my configs are stored in respective app's directory in a `%gconf.xml` file. Are you sure that wifi.conf is managed by gconf? Maybe it's just some random file that was put there by a broken app?
Standard ini files: ...what? Take a good look at all non-GNOME and non-KDE config files. Which one of them are ini files? I dare you to point even 3 non-GNOME non-KDE apps that use the same config file format!
Not removing configuration: yes, GConf doesn't remove old configuration automatically. Guess what, neither does everything else. Uninstall nano and /etc/nanorc will happily stick around until you manually remove it.
'find' not finding anything: I guess you didn't use find correctly:
Memory usage: straw man. You would be right if there are hundreds of daemons each eating a few hundred KB, but there aren't: there are only a hand full such daemons. Okay, so gconfd-2 eats 2.3 MB of private RSS. I was wrong. But still not bad since there's only one instance per user. However the comparison with Vista is totally straw man: fact is all those daemons together eat nowhere as much as memory as Vista. They provide useful services for a reasonable amount of memory, so all is well. Memory usage is a trade-off, zero memory is only possible if there are zero features; if you want to have all your RAM available why don't you go use your bash shell with no 'ls' or anything else installed?
Grouping services together into a single process: yes, you can save memory, but is it worth to? Suppose we have a low memory system with only 128 MB of memory. There are about 10 GNOME daemons, each with a private RSS of between 500 KB and 2 MB. I'd say the total memory consumption is 12 MB. Suppose you group them together to save the process overheads, and save 30% of memory. Memory usage has gone down to 8.4. Compared to the 128 MB of RAM you've saved 2.8%. Whohoo! Now was that worth it? I think developers have better things to do with their time than to save 2.8% memory on a 128 MB system from years ago.
As hardware capacities continue to rise, the point of diminishing returns draws closer and closer: soon the developer will have to spend 100 hours of time just to reduce the already tiny 10 MB memory usage by 2%. All this to please old-gregg who would otherwise continue to complain. Now do you honestly think all that labor is worth it?
I 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.
Those 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.
You might want to take a look at Augeas (http://augeas.net/) which offers standard "lenses" (ie. parsing filters) for pretty much all Linux /etc files.
I 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).
gconf 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.
Are 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.
I agree that the registry is a mess and probably badly implemented as well.
But a few of the criticism coming from the linked blog seems of the form "the Windows Registry is only compatible with Windows".
Since the Registry is very specific to the current version of Windows the user is running I don't see why, from a technical point of view, should effort be wasted in trying to make it more compatible with other platforms or versions of Windows.
The registry is an abstraction and there's only a few supported ways to access it (regedit, .reg files and the registry API basically).
The linked blog has created an new way to access the registry that happens to also run on Linux. The larger project (http://libguestfs.org) aims to be able to make changes to virtual disks that comprise virtual machines without having to actually turn them which is pretty neat if the same registry tweak needs to be applied across a bunch of machines. But that explains why their new registry access api needs to be compatible with the various windows OSes.
Yeah, I saw that. My point is that the registry wasn't designed for that.
I'll be the same as complaining that the format of the /etc files is not well document, is not standard across different flavors of UNIX and everyone sticks whatever they want there.
It isn't really the same. Anyone that needs access to something in /etc can get what they're looking for without having the first pierce a difficult binary format. Deciphering what they get back is another issue, but typically it's just a text file, so you can generally figure out how to parse it if you need to.
Yeah--Why does it matter that the registry is endian-specific? Doesn't Windows only run on little-endian processors (x86, x86-64) or am I mistaken?
Is there any reason why a new version of Windows couldn't do away with the registry and create a layer of abstraction to allow programs in a "compatibility mode" to run normally but have its registry interactions translated to the new system? Wouldn't that be a similar principle to what Wine does?
It would mean that if you port windows to a large endian machine, then you can't share registry files (ie. as in roaming profiles). It's not as much about the file format as it is about the implementation (simply dumping C structures to disk). I think what the author is saying is that it's just a crappy implementation.
I don't think there's any way at all to share the whole registry file even in the same endian machine. It wouldn't fly anyway since it's very machine specific.
The way you'll share parts of the registry will be using .reg files, those are just plain text so could easily be read anywhere.
The windows-specific issues are probably a large part of the problems that happen when you try upgrading Windows versions, e.g. XP to Vista, Vista to Win7, and no end in sight.
Based on what the article points out, I would speculate that Microsoft spends a lot of energy trying to catch and fix all the ways the registry migration breaks when doing an OS upgrade. Not only is that is all wasted energy, it will never hit 100% success rate because there will always be something the porting engineers never saw in their systems.
Not to mention - the registry hive file is an internal data file for Windows; why would the author have the expectation that it would always have the same format.
It helps to realize when and why it was created. The internal lore, as best I recall it is below...
At the time, application developers stored settings in INI files in the \Windows directory. Reading this name=value file was very slow. The registry was an attempt to centralize storage of that data, speed up application startup by reducing the time required to settings data from it, and to respond robustly to disk corruption.
Of course, after it was created, everybody and their grandpappy (COM, MSI/Darwin, etc.) decided to abuse it as a general-purpose store. Now that XML file load is considered zippy enough to be done at application start, developers are encouraged to have a private configuration file in their own application directory and per-user ones in the per-user directories.
It sounds like the Windows registry is an ad hoc, informally-specified, bug-ridden, slow implementation of half of a filesystem. (Amazing how Greenspun's Tenth Rule can be slightly adapted and apply to so many different situations)
If you should find yourself creating an ad hoc, informally-specified, bug-ridden, slow implementation of half of X, stop! Throw it away and use X instead. You'll save yourself and everyone who has to interact with your system a whole lot of grief.
And since a filesystem is an ad hoc, informally-specified (or unspecified, how long did it take before linux could read ntfs?), slow (for some things: no indexes), bug-ridden (FAT 8.3 name limit, limited metadata such as file types), implementation of a database...
But filesystems have been in use long enough that most bugs have been fixed or worked around in the tools. And of course the guys who invented the 'filesystem' didn't have any databases to use instead.
Some would argue that X is an ad-hoc, informally-specified, bug ridden, slow implementation of half a window system. The specifications are pretty clear, even if some are honoured more in the breach than in the observance, but otherwise they'd be right. ("This is not a bug; this is a design decision.")
How would global shared settings look without a registry? Like Unix configuration files. This is a step backwards, as there is no unified way to read Unix configurations. Some things are stored in environment variables, some things are stored in XML files, some things are represented as special files, and some things are stored in INI-style files. Something like window color would be handled by the display manager, but other configuration settings would need to be hunted down at runtime.
What's really better, "read system.window.background.default_color.[rgb] as ints," or "parse /etc/x/conf/x.conf as an .ini file, look for the variable background_color. It is stored in the format (r,g,b). If it is not present, the default is (255,255,255)."?