Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What are the main differences between the Windows registry and the approach used in UNIX/Linux, and what are the advantages and disadvantages of each approach?

share|improve this question

closed as not constructive by Mat, jasonwryan, Michael Mrozek Sep 13 '12 at 14:29

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Hmm, gconf is something similar to registry, used by gnome. – warl0ck Sep 13 '12 at 7:23
-1: too many questions, subjective arguments, and inviting discussion. – Sardathrion Sep 13 '12 at 7:25
@Sardathrion, how is "too many questions" a bad thing? Is it against the site policy? – missingfaktor Sep 13 '12 at 8:06
@Sardathrion, and how is "inviting discussion" a bad thing? Perhaps the question clashes with community policy as it is phrased, but I am sure it can be objectively answered. As such I will appreciate help in rephrasing it. Apparently genuine curiosity is a bad thing to some people. – missingfaktor Sep 13 '12 at 8:07
"What are the main differences between the Windows Registry and the approach used in UNIX/Linux, and what are the advantages and disadvantages of each approach?" – D_Bye Sep 13 '12 at 10:04
up vote 3 down vote accepted

There is no real cognate in UNIX, but as wollud1969 says, /etc comes close. That, though, is only part of the story. You'd also need to consider things under /var (for information about installed software, running services, etc), /usr/local/etc (at least on FreeBSD and certain Linux distros) for configuration information for installed third party apps, and of course each user's dotfiles, which customise how software works for them (roughly equivalent the the HK_CURRENT_USER hive in the registry). Then there's /dev for device interfaces, /proc for running process data, and the kernel itself (either through sysctl, a kernfs virtual file system, etc). Depending on your particular platform, there may be other places to look, too.

The primary advantage in the UNIX approach, from my perspective as a UNIX user these last 12 years, is that application config files, wherever they live, are usually just plain old text files, so can be read and edited by plain old humans. (Except, possibly, the sendmail config file, but that's a completely different religious war...). Many applications (browsers, desktop apps, etc) create config files for you, but they are text files, and the apps usually won't stop working if those files are then edited by hand, provided the edits don't break their syntax. The downside, though, is that there is no universal config language, so you need to learn the syntax for each app you manage. In reality, though, this is only a small annoyance at worst.

The Windows Registry was developed, at least in part, to address a similar state of affairs that was deemed problematic by Microsoft, where application ini files were not centrally managed, with no strict control on what values went in them, and no standard location for software to put them. The registry fixes some of those concerns (it is centrally managed, with specific data types that can be stored in it), but its disadvantages are its binary format, so that even experienced Windows admins need to use a GUI tool to look at it, it's prone to getting corrupted if you lose power, and not all software authors are sufficiently conscientious to clean up after themselves when you decide to uninstall their kewl shareware app. And, as with almost any other file in Windows, it's entirely possible for the various components of the registry to become fragmented on disk, resulting in painfully slow read and update operations. There is no requirement for software to make use of the registry, and even Microsoft's own .NET platform uses XML files instead.

The Wikipedia page about the registry is quite informative.

share|improve this answer

It is certainly not directly comparable, but I would think of the /etc directory as the counterpart of the Windows registry.

One major advantage, at least from my point of view, of the /etc directory is: you can open each and any file with your favorite text-editor and read, hopefully understand and modify or fix it.

The Windows registry is stored in some specific binary format and you read/write it with the registry editor, which does not simply show you what's in the file but which interprets it for you. Furthermore, everything is in one big file.

share|improve this answer
There is no requirement for any application on linux/unix to store its configuration in any particular way, nor is there any dependency on that configuration from other applications, normally. This is not true of course for cases where one application explicitly depends on others. Having said this, I think there is a lot of flexibility that comes with this model. Transparency has been mentioned of course, but I think the flexibility is critical today where systems could be built in many different ways and apps could be on local disk, NFS, etc. File structure freedom is important. – slashdot Sep 13 '12 at 12:57

Why it is criticized so much? For me it's just for one point: transparency. The registry doesn't has any, imo. Objectively:

  • it is error prone when tweaking around
  • can get fragmented
  • crap entries are often not deleted when deinstalling software
  • too many key types (DWORD, QWORD, string, binary, unicorns etc.)
share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.