Slashdot Mirror
How to Fix the Unix Configuration Nightmare
jacoplane writes: "There's an interesting article on freshmeat talking how sorting out some kind of standard for configuration could really help Unix systems could be more user friendly. The article points out that since Apple has managed to build a quite usable system on top of NetBSD, it should be doable to do the same for open-source interfaces."
The part that makes such a system really useful however, is a standard agreement of which information is stored and what it means. This is where the Windows Registry falls down. And Unix is even worse, because all it has is some common soft-of-agreed-upon shell variables, like $EDITOR etc.
Apple is able to do this better because they set the standards for the OS (even more than MS). The can have one central "registry" for something like default associations of MIME-types with particular applications and define an API so every application can use it and a user doesn't have to change his settings in his browser AND his mail client AND his ftp client, etc.
Given the diversity of the unix crowd, the latter seems difficult to me. Maybe they can include it as part of LSB for a start?
Idempotent operation: Like MS software, wether you run it once or often, that doesn't make it any better.
In the writer's outline section he has a few bullet-points that scream "XML!" (I'm paraphrasing here):
1. A core system to handle parsing, verification, etc. -- If app configs were based around XML, you could use any of a dozen XML parsers out there.
2. A configuration format description file. -- Hmmm, sounds like a DTD...
3. OS-neutral. -- XML was meant to be portable from the get-go.
The other items lined up pretty well with what XML is all about as well. Anyway, that said, I'm not so sure this'll ever happen since, from a developer's point of view, it's a lot simpler to slurp in a bunch of lines from a text file with fgets and chop it up into words than to have to somehow link in a third-party XML parser.
Because there is only one captain on the ship, Apple. Good luck fixing it in the Linux world. The only way it might have a chance of working IMHO is if such a proposal gets included the Linux Standard Base. Here's a bold idea, why not copy the way Apple does it??? No need to reinvent the wheel...
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
A brilliant article, and a subject which I have tried before (with little success) to broach with various OpenSource developers. Unfortunately the comments demonstrate the lack of understanding that is all too common in the free software world: an inability to distinguish between apis/formats and software implementations; and an unwillingness to move to a more user friendly system.
GConf and Webmin, for example, are not solutions that address the problem posed by the article. Other comments completely lose the plot: this is about a common configuration format which can use metadata to provide for configuring just about any application, it is not about creating an all-encompassing configuration that will give settings to all applications everywhere for all time.
Gconf is half of the solution at best. It provides a library (common abstraction) for accessing the data. But an application still has to have explicit knowledge of the data in order to act on it. A configuration framework describes this knowledge to allow any compliant application to act on it.
Sometimes an example is worth 1000 pictures (and hence about 1000000 words), so consider a simple packet filtering application with an ACCEPT list and a DENY list, which can listen on several interfaces.
Such an application would have a meta-data configuration file (say /etc/conf/meta/filter.cfg) which specifies:
section name=interface count=multiple type=ipv4 ; section name=accept count=multiple type=cidr ; section name=dent count=multiple type=cidr. Now any application can access the packet filter's meta-data file, and the real configuration file (say /etc/conf/filter.cfg), and understand the meaning, to a degree, of the configuration. The types "ipv4" and "cidr" will have to be primitives for the configuration framework.
Thus a general configuration application could present a tree which has three branches (interface, accept, deny), each of which displays a screen with a list. Appropriate entries can then be added, modified or removed, reconfiguring the packet filter without the configuration application having any prior knowledge of the filter's configuration or requirements.
With adequate forethough (for the categorisation and types required) such a system can be extremely powerful. A single configuration library can be used by the application, as well as GUI and CLI configuration clients. You could easily have a command in a script: config pktfltr add -section interfaces -value 1.2.3.4 .
A common library like this can also provide powerful features that a lot of applications lack, like local (user) settings which override global defaults. The library can maintain global, group and user configurations for each application, and getting/setting preferences will take the overlays into account.
Implementing such a system would also provide an ideal opportunity to introduce configuration versioning. CVS (for example, or arch, which includes directory versioning) could be used to maintain various versions of the configuration files in /etc/conf.
Arguments about diversity are largely moot. The data format is independant of the data in any well-written program. .INI files, Bind-style files, XML files and SAMBA files can all represent the same information, but they look different. Some are arguably more efficient in some situations. Even the feared Windows registry has the same functionality ... it just makes the (fatal) error of storing everything in a mostly inseparable datastore (sortof like an /etc/conf directory in which you can't treat the various files separately).
This is a suggestion which needs to be followed through, and supported by the community.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
Sure, installing software is easy. Unpack and compile. We are talking about configuring software.
Like getting sendmail to rout and forward mail, apache to serve up web pages you want, BIND to bind names to IP address, etc.
These tasks arn't "hard" or anything, but they do require a lot of reading on the part of a Newbie. In the windows world (don't know much about OSX) Most of that stuff can be done via am intuitive GUI.
Flame me if you want, but I'd greatly prefer a system that didn't require me to learn diffrent config file formats for each service I want to have running... or deal with a hodgepoge of 'easy config' program hacks.
A simple, standard configuration system is definetly the way to go.
autopr0n is like, down and stuff.
On that thread what the hell is /usr/etc used for, or /usr/local/etc? won't it make more sense to move /etc here instead?
Do we really need a central registry type file like the article proposes, surly isn't a front end enough, I can't understand what difference this would make. Having a central file which contain's everything like System.dat seem's to be a major security floor in windows since if you can crack that file you pretty much have root on the machine. Not being able to set different permissions for something like fstab or shadow would be pain. Although to be fair the article proposes it as a backup. If it ain't broke don't fix it.
Apart from these questions I think that this was a pretty good/fair article, although I thought that it was a bit unfair to compare linux to windows/OSX since they are completely different OS and something like creating a central config app might work to make linux less customisable IMHO. Most distro's tend to have app's along these lines anyway, what the hells wrong with DrakConf?.
Pianist : Some jerk whos taught themselves how to type in rhythm
Yes, I know this is a comment on freshmeat (I wrote it).. but it pains me to see so much incorrect/incomplete information here that people just believe for lack of experience with OS X.
/etc (which is a symlink to /private/etc):
/etc and puts it in a
/etc style formats
/System/
/Library/Preferences, Network-wide app prefs (only
/Network/Library/Preferences, and User app prefs go
/etc, as nothing there is meant
---
MacOS X's solution to this problem is a couple levels
deep. There are three (?!) systems for configuration:
(1)
It's still there, used for a few things. But not much.
More or less just stuff that runs before everything else,
or stuff that apple doesn't have much control over, like
Apache.
(2) Netinfo database:
basically takes a lot of stuff out of
"registry", this registry is accessible over a network
connection for remote administration and such. You
can also do some funky server/client stuff with this too.
There's a command line interface to it that lets you
read/change 'keys' and also dump out certain keys in
well known
(3) Property Lists (.plist):
This is the way that just about all configurable
information in MacOS X is stored. There are a couple
different kinds of plists that the Core Foundation
libraries understand, but the most prevalent of which is
the XMLified version, the others are either vestigal or
are used primarily for localization of strings. Every
application (well, bundled app) on the system has an
info.plist file that has application settings that the OS
reads from on app startup, but you can also put your
own tags in there. Applications also have the option of
putting their own tags in the Resources subdirectory in
their bundle, which is the preferred way. OS specific
preferences (requires admin privs) go in
Library/Preferences, System-wide app preferences go
in
applicable if you have OS X Server on the network) are
in
in ~/Library/Preferences.
The Core Foundation framework manages more or less
all of the work. They'll find the plist for you, let you
work with the data structures, and serialize/deserialize
it to plist format. It's really quite nice to use. Just
about all of the data structures in Core Foundation are
serializable, even the property list data structures, so
sometimes you'll see property lists with serialized
property lists inside them.
As far as unified configuration interfaces go, there
really isn't a need for any in Mac OS X.
You're on your own with
to be novice-tweaked anyways (In OS X).
There is a GUI NetInfo Manager and command line tools
to configure the stuff in that database (nothing a
novice needs to touch).
Configuring the plists is primarily done inside the
applications that you use (since it's so easy for the
developer to use Core Foundation to read/write
property lists), there are no separate configuration
programs, but there are command line tools for working
with plists. If you're using the developers kit, you get a
little (not very poweful and pretty inefficient) program
to edit plist files graphically, but otherwise you either
do it by hand with a text editor or the command line
tools and risk breaking things or let the apps take care
of it themself.
BTW, all of the Core Foundation stuff is available in two
flavors: C, and Objective C. The C libraries are pretty
straightforward and work in all situations, but if you're
writing an app using the Cocoa framework in Obj C, it's
way easier.. though there are a few little peculiarities
about the Obj C implementations. The bonus is that
you can use both at the same time, and Core
Foundation types / Cocoa instances are interchangable
by some voodoo that Apple did. If the Cocoa
implementation doesn't work right (As with serializing a
plist that has NSNumber Boolean types), you just use
the Core Foundation implementation and a typecast..
voila, one line of code changed and everything is
happy.
It took MacOS X for people to realize that this was a problem in UNIX? Please.
/etc/registry.conf. There is no reason it has to be binary.
The reason UNIX and UNIX applications are hard to configure, in most cases, is because Open Source programmers are lazy.
This is obviously a blatent generalization so I will explain.
The old adage is that an Open Source program gets written when a programmer has an "itch" they decide to scratch. The problem is that very few people are itched by configuration. You may write the best web server in the world (Apache!) but by time it comes to writing the configuration manager for it the volunteers start falling away.
It isn't very fun writing a bunch of dialogs, windows, buttons and such to make a nice configuration for a program. It's kinda like documentation (and we all know the state of docs for many UNIX programs).
I see examples of this every day. I have a Mac OS X using friend who sends me the URL of every new program he decides to use. It's incredible how many of them are UNIX ports with a beautiful configuration manager stuck on. Mac programmers hold themselves to a higher level of user experience and UNIX people need to get on the boat.
What's needed isn't a global, all dancing, all singing configuration system. What is needed is responsibility in programming.
P.S. Everyone always whines about the Windows registry because it's binary, you can't edit it blah, blah, blah... But the fact is: It works. The average user never cares to edit it because they config their programs from WITHIN their programs. If something is truly needed, do the Windows registry in text file format. Make it