Unix is steadily evolving into something much easier to use. The trick is to find tools that make things friendlier, but which fit in well with existing tools and are easier for people to take and use for new projects. Read more at Freshmeat.
How to Fix the Unix Configuration Nightmare
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Things will never change because a lot of Unix users seem to have opinions like this (from the article’s comments) :
“Why do you need single configuration interface to
all things that can be configured? Are you too lazy
to learn how to configure each single one by one?
Are you too lame?”
“Can’t you just learn how to configure these? I,
personally, like learning stuff. Maybe you could give
learning a try.”
Also the author didn’t seem to know anything about the windows registry.
“I don’t think I need to go into much detail as to what a mess the Windows registry is. It does provide a certain amount of power for graphical applications, but the text-level access is shoddy and cryptic, and a binary database seems to be an inherently unstable and inflexible way of storing data. ”
Uh ? Did he know really what the registry is ? I think there’s some confusion here 🙂 And what he means by “provide a certain amount of power for graphical applications” ???
>>Unix is steadily evolving into something much easier to use.<<
Yes, it is. Mac OS X.
Compare some key random key you open with regedit to a default httpd.conf and then tell me where you more of an idea how to get things right.
Ok there are some config files that are not documented that much but if you do only have the windows registry and regedit you can configure hardly anything. It’s all about the frontends IMHO.
“Compare some key random key you open with regedit”
Well … registry database is NOT intended to be accessed in a randomly manner. You know config files under Linux but not registry under Windows. So you prefere config files. I don’t know config files very much and they look like a *total* mess for me, and registry is VERY easy to naviate in, and think is a way better classified way to store general informations and setting.
It’s not because you don’t know how to navigate in registry that it’s a mess.
When things are in config files atleast you know you can read the info. Some keys in the registry are number, and weird ones at that. Screw up a config file, what do you lose? One service, screw up the registry and you screw up your OS. Its utterly irresponsible of them to put the app’s config stuff into the same pile as the OSes.
Which to prefer is a user preference though. I prefer config files, but i can see how some prefer the registry, hey its point and click.
Its true that people are afraid of learning though. How often do you read a manual by choice? Everyone wants to know everything about something but its very rare that they want to put in the time.
“Why do you need single configuration interface to
all things that can be configured? Are you too lazy
to learn how to configure each single one by one?
Are you too lame?”
I don’t think most *Nix fanatics have gotten it through their thick skulls that most ‘common’ folks just want to use their computer to get things done instead of dicking around with configuration files all day.
Any time you have to go and edit a configuration file, if the programmer is at all concerned with ease of use, then he’s not doing his job if the front end does not provide a means to let the user set preferences without having to fire up vi or pico.
As for the Windows registry, the only time I’ve really needed to use it is so that I could make my Windows box communicate properly with Samba (clear-text passwords).
The Windows registry is evil.. especially when it corrupts itself at random intervals. BeOS did it right in having a central location for config files, use seperate files and/or dirs for each app and you could create a gui config tool to read and modify everything in the dir, add a central data location and back ups couldn’t be easier.
“The Windows registry is evil.. especially when it corrupts itself at random intervals.”
That’s why the best is to have your registry database in a NTFS partition, controled under a safer kernel (NT/2K/XP). In those conditions, I can’t remember any registry corruption (and that include many years of intensive utilisation and registry manipulations).
“BeOS did it right in having a central location for config files”
Right on ! Registry have problems. Spreaded config files is a problem. BeOS, IMHO, get it right by getting best of both worlds. What I like the most with the registry is the way everything is centralized, which is way more useful than spreaded config files. But config files are a lot easier to manipulate and update (what can it be easier than a text file?).
So that’s why I think the BeOS way to handle this issue is the way to go.
ARGH! Unix’s configuration problems go SO much deeper than standardizing the configuration files. It goes straight to the core of the unix logical filesystem: Why is everything important in /etc ?
I’m not sure if many geeks, Unixphiles or not, have really stopped to ponder these kinds of things. “Etc” is Latin for “and the rest”. And this is a good place to put all the files that are 100% critical to the running of your computer? We need to be able to examine the really basic and simple questions like ‘where do super-important files go?’ and answer them in a way that makes perfect sense to someone who is computer illiterate.
Also, does anyone really believe that Unix’s configuration problems have anything to do with each app scratching it’s itch it’s own special way and that this isn’t actually a symptom of the greater problem of architectural cruft?
The idea of a registry is sound. But there’s no need to put it physically in one location so long as the interface is in one place. RPC/SOAP is perfect for this and can mask the underlying implementation details.
For example,
Software calls SOAP interface,
SOAP parses/edits crappy unix configuration files
SOAP responds accordingly to the software
Legacy software just reads the crappy unix configuration files.
Behind the scenes of course there’s a need for something better than crappy unix configuration files. Self-descibing XML files would be best – and these can be made into crappy unix configuration files for legacy apps (XSLT to the rescue).
Of course I’m not going to do anything about it. I’m not much of a programmer. I’ll write the XSLT but that’s it.
Later, chumps
You can’t compare the Windows registry with Unix config files, the two are only remotely similar in that they both exist on computers.
First of all, config files are good and the registry sucks. Second of all, config files are clean, or can be cleaned very easily. Try installing any Windows app and then try deleting everything out of the registry cleanly when you want to uninstall it. The only way it can be done is with a diff program run on a dump of the registry pre-install against one done post install and then a whole lot of manual deleting of GUIDs and other such crap. Most people don’t know how to do that, so anyone that thinks Windows configuration is easier than Unix is quite ignorant.
Some here today are comparing Windows “wizards” to the vi editor under Unix. This is also an invalid comparison. Either compare vi config file editing with regedit editing, or compare the myriad front ends to config files that exist in Unix to the one “wizard” that exists under Windows.
At least in Unix you can configure everything. In Windows you’re stuck to what Microsoft wants you to do.
I think that OSX could provide the best of both worlds with the .app ideal.
Essentially, the problem with installing something on a computer is that it then spews files everywhere: installing on UNIX means there is a file in /etc, a “dot” file, a file in /usr/local (or wherever…), some files in /lib, and then a crapload of spool files, log files, etc. etc. etc.
The genius of the OSX .app is that it does two things: 1) registers with the OS 2) has a defnitive directory structure. For example, there is/can be a Library and Preferences directory for each .app.
Note that “registering with the OS” simply means that it kleeps track of where a .app is… the “registry” does not have to keep track of configuration, etc.
THEREFORE, what could happen is the OS could keep track of what is installed, but then allow each app to have its config files in its own directory; delete the .app, and the config files, logs, internal libraries, etc. etc. etc. go with it.
Furthermore, because there is a definite directory structure to an .app, you could have a /etc directory that is simply LINKS to the various /etc directories in the individual .apps. So, everything is in one place and in all places at once.
For the *NIX heads out there, you could have the config in the .app’s directory AND in the /etc directory. For the GUI people, it would be simple to make a GUI config tool that simply reads a .plist and creates a GUI config tool based on that (there is already a project to do that in Linux, but no one uses it because of the “GUI tools suck” attitude).
See? The advantages of a registry, the advantages of *NIX config files, the advantages of the traditional Mac way of doing things… and no disadvantages!!