Microsoft stores system configuration information in binary format in its Windows Registry, but other vendors take different approaches to achieve the same goal. MacOSX uses text files in XML format, while Solaris features a more complex system instead. Linux still uses flat text files for configuration, however Red Hat encourages the development of GConf, a registry-like system and library, that programs can use to store key-value pairs persistently. Read the interesting article at ComputerWorld.
Is it just me or is the Gnome project out to copy every damn thing Microsoft does? Yeah Gnome!
Since XP came out, and I began using it at work. I have had the registry hive magically get corrupted on three different occasions. Not only does this destroy my application configuration data, but also has the side benefit of not allowing Windows to boot.
By storing everything in app specific files (I like the XML idea, but flat files are okay too) I don’t have to worry about it. If one file goes bad, I can just re-setup that application as opposed to having to first repair my OS and then reinstall/reconfigure all my apps again as I have to do under Windows when the registry goes South.
Why bring all the headaches to other operating systems?
Sounds like OS X has it right. Binary config files are a constant
source of trouble on computers, and bundling a whole heap of them
together into one giant file is madness.
You probably do need something a bit more formal that a plain text
file, and XML is it – it can still be checked out in a text editor
when there is a problem.
With things such as gconf you dont have to repair
your entire system, just fix/delete the files for the app
that gone bad.
I have to agree, applications should keep their global configuration/preferences in a text file (using XML to structure it is a sound idea though) in that application’s own folder. User specific data should be kept in a prefs folder within the user’s home directory and be named after the program, but again text/XML should be the format.
The system should do much the same, having a global prefs folder and a system folder within the user’s prefs folder for per-user config (screen res, colours etc). Each sub-system should have its own file, this minimises risk of corruption and is more modular.
Where binary info is *needed* (such as an image for a background etc) the file should be stored as-is and a URL to it kept in the prefs. Other binary type data can simply be held as hex strings in the prefs.
There was nothing per-se wrong with Windows 3.1 ini files other than the nasty habit for apps to store there ini files in the Windows system folder.
Of course, most users shouldn’t worry or care how their prefs are held, as they’ll only use a suitable GUI for editing them…
A registry is a good idea, a very good one. You can centralize everything, and you have one interface for applications to use (i.e. getSettings(…) or something) instead of having to parse something manually.
Another benefit is that you can have settings that are shared by many applications. Many are the times that I have been pissed that I have to change something in every program (the office package seems to have recognised this, as settings in one app shows in the other etc), and I want the same shortcuts in every editor (forte just sucks so bad). Very convienient and good for the user.
Next to implementation. Just because M$ went with a database style engine (that has worked just fine for me in 2k and XP, but I know that it’s fragile, and M$ really should fix this) doesn’t mean everyone else has to. You can even save everything in a directory structure with XML files, or in one huge file in your own evil binary format based on klingon.
The point is this:
1. Uniform interface
2. Parsing/saving/etc done in one central piece of code
3. The engine can be anything from a huge file, to dirs with XML to a real DB.
4. Easier to share settings between programs
5. Easier to have defaults for all user
6. Possible to have a central copy of all users settings, plus the defaults, to make it painless to restore a users settings, either on a new install (new machine for instance) or to recover a crashed machine (can’t save yourself from faulty hardware after all).
So, the idea of a central reposatory for settings is great. Doesn’t KDE already use something along the lines of that already? I much rather see their solution gain ground, I am very far from impressed by gnome and gtk.
I haven’t read the article yet, but if RedHat wants to offer the Win Registry like environment, they are doomed ๐
One of the reasons I like Mozilla and Rebol is – they allow me – copy & run! If I reinstall Windows, I don’t have to reinstall my favourite apps.
We know the term “dll hell”, now we also know another one “registry hell”.
When we started to develop our IS in our company, I told my folks ironically I will break their legs, if they touch Win Registry. We developed our own simple method, where during the start of IS it just looks into central store if there is something new. And if so – just copy & run – no need to install and visit our sales ppl. Now we all value the decision, especially if there is the need to completly remove Windows and install it from scratch – one less app to reinstall ๐
XML aproach or flat file one seems to be OK for me … Maybe even binary format would be OK, if not related to OS (re)installation …
Just my opinion ๐
-pekr-
set a standard for xml or plain text config files instead of collecting all settings in a single point of failure.
well, before I poo poo the Idea, I would like to look at the format of the information. one advantace of having binary files is that the information is already machine readable.
though, I think it is already done up like that with text files, no? do each Deamon not look at the text file the compile the information into machine readable language when the deamon starts?
if so, I also see no reason for a binary layout, I would like to have all the config files XML-ized though and the deamons corespondingly, this would facilitate simple script writing to do configuration.
>>MacOSX uses text files in XML format.<<
Microsoft is doing something similar with it’s MSN “Browser”. Some features (“Favorites comes to mind) is stored as an XML file deep down in the Documents and Settings\%username% profile directory.
Like all things, a nice blend of flat configuration files and a binary registry is probably the best bet.
>>I have had the registry hive magically get corrupted on three different occasions<<
Yeah, me too. Back up your system state on a regular basis, and get updated motherboard drivers (corrupted registries are often caused by this – esp with VIA chipsets).
I never understood the appeal of the registry, at least implemented Windows-style. Great, a central place for all of your prefs… Well, that’s what /etc and ~/etc should be for. Yeah, there’s no ~/etc, but there should be- I hate having 100 .something folders and files in my home folder. Rather like Mac OS X ~/Library, where apps can store prefs and other user-specific info. Works rather well.
Using XML isn’t a horrible idea either. Doesn’t have to be XML, but as long as it’s a standard format, system wide, you can have an API that has the same advantages of a Win32-like registry, but without risking corruption of the central store. You also have the advantages of the just-flat-files method. Summary? Clean, easy API to read and write prefs without having all your eggs in one (in Win32’s case- error prone) basket.
It’s a shame Unix seems to think that having an infinite number of different formats for pref files seem to be a good idea- it really gets in the way for no benefit.
Why do we need a special GConf? If it’s just key->value pairs, why not just have a berkeleydb prefs.db in /etc?
But a db-like filesystem all together, with prefs as part of a browsable and editable (by the user, if needed) metadata tagged on the application itself isn’t a shabby idea. Similar no-lose-situation as Apple’s “plists w/ API” solution, but bringing it to all data with all apps. Did BeOS apps keep their prefs in the tags allowed on files?
Aren’t one supposed to be able to hit the spacebar during boot in order to use the latest working registry under windows?
The Windows registry is really weried and it’s hard to repair.
The XML idea is quite ok, all the os has to do is to give a little support for XML, and everybody can understand it.
I’m with you, I have never liked the registry! granted it being a DB (correct me if I’m wrong) it has faster access time, but give me some kind of flat file (or XML) anyday. Besides software use the registry as dumping grounds for all kinds of stuff that you don’t need, some even use it as temp storage and that is not what it was intended to be used for.
According to the GConf web page it is intended “to make application preferences more manageable for system administrators” what is wrong with opening up a text editor and modifying the settings there?
GConf holds the registery of every app locally. for example Galeon saves all the config files in .Galeon/ and Gnome saves it in .Gnome/
Microsoft has some good stuff when it comes to usibilety, and that’s the only thing that the open source community lacks at the moment.
you can achive what the registry provided by having all the config files stored in thesame directory in XML format, then you can make a grafical front that seperates out the settings of applications into groupings and then have a nice easy check, point, click interface with descripors of what the configuration does.
your right, we can do it better, and it should be done with XML files.
Jeremy said:
> one advantace of having binary files is that the
> information is already machine readable.
Text files are also already machine readable. Binary or text, you’re still going to have to parse and encode to whatever format- binary or text- you use, unless you’re using serialized objects, which I image is pretty rare when a lot of the apps are in C++ (not so dynamic) and C.
Fizz said:
> I’m with you, I have never liked the registry! granted it
> being a DB (correct me if I’m wrong) it has faster access
> time, but give me some kind of flat file (or XML) anyday.
You can have both- a DB-like interface that’s easy to use, and faster, and having localized XML files.
> what is wrong with opening up a text editor and modifying > the settings there?
Inconsistency. As many different file formats as there are apps. Very bad. Inelegant and ugly.
I’m glad to hear that GConf has this nice interface to a distributed, file-based and standardized format for prefs.
“Why do we need a special GConf? If it’s just key->value pairs, why not just have a berkeleydb prefs.db in /etc?”
As far as I know with GConf and application can be notified if it’s stored preferences change for some reason (even over network).
So you can just tweak around in gconf-editor and watch your apps react on that (e.g. set a new metacity-theme …). Isn’t that nice?
While GConf may be similar to the Registry in that it provides a single uniform interface to configuation data for applications, it is far more resiliant. The default setup is to use multiple xml files (one per app as it happens) as a backend, and it can also be configured to use flat-text or anything else as the need arises. It has all of the benefits of traditional UNIX dotfiles, is set out in much more sensible fashion than the Windows registry and is not dependant on GNOME at all. All this FUD about it being the new Registry for Linux is so depressing.
With .NET, Microsoft also uses XML config files instead of the Registry.
> All this FUD about it being the new Registry for Linux is
> so depressing.
A shame, isn’t it? Too many Linux users aren’t in it because Linux meets their needs (pragmatism), but because they want to be in some club of cool hackers who like to rebel against ‘Micro$ux!!’ just because it is the mainstream. gotta be a part of some club, don’t matter which one, if you’re trying that hard you’re still lame.
I had my first trip to /library in OS X The other day. I had a system preference that got “stuck” somehow on the wrong value. I went into my library and opened the XML preference file (.plist) and fixed it right up, with no tech support call needed. You guys who read this forum are, no doubt, heavy-duty developer/IT types, but for a lowly “user”, the experience felt a little empowering. I was afraid that when the Mac moved to UNIX, it would be hard to “fix” by the average joe. Thankfully, that has not yet proved to be a problem.
Right… let’s take important application data and store it in a proprietary database that is annoying to access, must be loaded into memory at all times, and if it gets messed up, forces you to reinstall your whole system and all applications.
The whole concept of having to “install” an application is so utterly stupid and outdated!
Look at BeOS (for example)… no installation is necessary, and if you need to store data, you can do it in /home/config/settings/ (you can even use the database functions of BFS to store attributes, if you absolutely need to).
And if you mess up your program somehow, delete the /home/config/settings files for your program, and the next time you run it, it will automatically reinitialize.
Most importantly, your drivers and OS level data is also in /home/config, so if you make a mess, deleting that directory will save you of a cumbersome reinstall!
Aren’t one supposed to be able to hit the spacebar during boot in order to use the latest working registry under windows?
One is “supposed” to, yes, but when the registry goes bad it doesn’t work (at least it hasn’t for me). I’ve always had to boot from the install disc and do a manual repair, which basically loses all your registry settings.
It’s like the Ignore button on the old GPF message box. You could hit OK and lose all your work, or you could hit Ignore all day long and get another instance of the message box for your own personal entertainment.
According to the GConf web page it is intended “to make application preferences more manageable for system administrators” what is wrong with opening up a text editor and modifying the settings there?
I just don’t like the idea of having all your settings in one file (the old adage about keeping your eggs in one basket).
I haven’t looked thoroughly at the specs, but if everything is stored in one file, I think that is a bad idea. If all your OS and application data is in one file and that file becomes corrupt it would be a giant pain in the butt – like Windows currently is.
I would wholeheartedly welcome the notion of putting all preferences in /etc under application directories and storing the information in XML. That would be great. If you had one tool that could access these disperate files (which wouldn’t be too hard) then all the better.
So, my Apache settings would be in /etc/apache/apache.xml and MySQL settings would be in /etc/mysql/mysql.xml. And so on.
I totally agree with you. Have you ever written an installer for a Windows program? What a complete pain in the crack.
I really like the way BeOS worked (works… worked… whatever).
RevAaron:
I’m not sure if you are trying to make a point, or have missed mine at all. I was stating that many people here at osnews.com have no idea what they are talking about, and are prepared to slag off a perfectly good piece of technology (GConf) without any kind of further research. Even after many people have said several time that it doesn’t use a single file for all apps, we still see people moaning that its rubbish and should be scrapped.
It seems that people should slag of Windows, will slag off Linux and sing the praises of the dead dodo that is BeOS. I use Linux because, for me, its more fun, and I couldn’t care less what others use, unless they ask my opinion, or provoke me. (Well maybe there is a little bit of politics – but the GPL is a discussion for another day).
This little article describes GConf. Everyone will be pleased to note that it currently stores preferences in xml files.
http://developer.gnome.org/feature/archive/gconf/gconf.html
The developer of it, Havoc Pennington, says that the backend for storing preferences is configurable.
“Replaceable backend architecture. GConf currently has a single backend that stores configuration data in XML-format text files; however, the architecture allows a Registry-like binary database backend, an LDAP backend, or even a full-blown SQL database backend. The backend used is configurable by the system administrator.”
GConf sounds good to me.
KDE uses a class called KConfig, which stores user preferences in ~/.kde/share/config/ in non-xml text files.
Hopefully people will be willing to adopt the better solution or at least work to be compatible.
> I’m not sure if you are trying to make a point, or have
> missed mine at all. I was stating that many people
> here at osnews.com have no idea what they are talking
> about, and are prepared to slag off a perfectly good piece
> of technology (GConf) without any kind of further
> research.
What part of my reply confused you? That same attitude which you just mention is the one I’m talking about too. The people that see the word “registry” associate it with “Windows” and “Microsoft” and don’t take the time to consider how useful it could be, or how much different the implementation could be.
> I use Linux because, for me, its more fun, and I couldn’t
> care less what others use, unless they ask my opinion, or
> provoke me.
I didn’t say you were of that type I described. But a lot of people are, especially those who think that anything that exists in some form in Windows is automatically bad- because they want so much to be different. You seem to have done research, which is exceptional compared to a lot of Linux users.
I went back and read my post, and see why you could take it as an attack on you. I didn’t know you even used Linux, but I’m talking about the morons who reject things before evaluating them simply because of it’s possible association with Microsoft or something else mainstream.
Rev Aaron:
Cool, glad we cleared that all up
Did BeOS apps keep their prefs in the tags allowed on files?
Naw, for the most part BeOS apps keep their prefs in ~/config/settings/
It would have been interesting if there had been a good way to store prefs in file attributes, but it would have been a little bit cumbersome. Apps would have had to create attributes for every single setting, for example you’d need a file like:
BeMail Prefs
With attributes such as PREFS:bemail-name, PREFS:bemail-pop3serv, etc. And that’s assuming that there was one standard file type for pref files (say application/preferences). That would create additional difficulties – developers would have to make sure no other app used the same PREFS:* attribute (unless they could share settings), and it would create a huge number of attributes for that one filetype (which would slow down indexing).
Another possibility would be for there to be a special preferences/* supertype and every app would create a subtype for each app (say, preferences/bemail), then create attributes for that type, then store settings in those attributes. Still though, it would be pretty inefficient – creating a new filetype and associated attributes for just one settings file.
Maybe Marco Nelisen’s pref_server solves some of those problems, but I’m not really sure how it works.
The problem with the win32 registry is that if one part of the registry is corrupted the thing won’t boot! Therefore if one program screws up the machine the whole thing is screwed. I personally liked win3.1’s flat text files better because the data was separated into more files therefore making the likely-hood of one bad file making the system unusable much less likely. Another advantage is that a flat text file tends to be easier to understand whereas the win32 registry looks very cryptic at times. I wish that windows would move all non-system data out of the registry into either a separate db or into just plain text.
I simply don’t care
have GConf make just my life easy since I can use that as a convenience lib to store and retrive the configuration data I need.
If I do need that my conf file is a database with loads of key even non textual I can use it
if I just need to care acout a pari of value I can even use some fgets …
Anyway that is a matter of needs as the win registry is.
app can avoid the use as they can use it, the same cames with the GNU/GNOME/KDE/*NIX/Solaris approaches.
If it suits you needs use that, if not take another way.
Why does one wants to create different partitions for each file system subtree on your machine ?
– one wants to be able to (un)plug these subtrees easily
– one wants to share subtrees with different machines
– one wants to tune partitions according to their use
same problem here with configuration data :
– one wants to be able to add/remove an application configuration without fscking the whole system
– one wants to share an application between machine, and perhaps the configuration files too.
– one wants to use whatever file format suits best for its application configuration.
The best approach here is perhaps a set of tools to (u)mount config files on a global config tree (registry), a good API to get access to this registry, and also a simple config file format natively parsed by the tools (XML like for instance). Whatever exotic config format would just need to come with the tools to access it in a standart way (like mkfs/fsck or perhaps a plugin architecture to the registry tools).
forgot to say :
IIRC, the MS Registry API allows what I described in my previous post, but for some reason (marketing I would say), MS decided to freeze the registry in one piece in their systems (well, I don’t know how the registry’s used on MS servers), so that the user loose all benefit from the registry system, apart from the configuration central repository aspect.
To bad…
There’s really no point in storing preferences as attributes, unless it’s preferences for a specific file perhaps.
Saving the preferences as resources is a better idea, and a lot of apps for beos does this allready(Net+ for example).
XML however, has some really big advantages.
MacOSX uses text files in XML format
Explain why it so bloody slow!
It’s a good idea for application to simply access to data with api library. But for edit directly this files by administrators, they must been in xml format. Binary is only intersting for a lot of informations in a same file (wrong idea). And you can’t add comment in a binary format !
Configuration data may lie in bare files containing simple
values. Imagine some kind of filesystem tree where key-value
pairs are mapped as filename as key and its contents as value and directories as internal configuration tree nodes. Diskspace losses are not a problem, eg. reiserfs already solves this problem by placing multiple short files in one block. This solution is both easy for machines and for people.