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."
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.
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
No no no. XML is not the magic solution to all problems in communication, data storage and usability. Using XML does have many advantages for some applications, like communicating over the internet, but I don't see how
<DocumentRoot> /some/path
</DocumentRoot>
is so much more usable than
DocumentRoot /some/path
The only thing XML will do if widely used for configuration files is make maintaining them harder for those who'd like to do that by using shell scripts or simple text editors. As a very basic example, using XML makes configuration files harder to grep. The above example might also be written like this:
<DocumentRoot>
/some/path
</DocumentRoot>
This is completely legal XML, but if you grep DocumentRoot this file, you'll get the following result:
<DocumentRoot>
</DocumentRoot>
which is probably not what you wanted.
Sig (appended to the end of comments I post, 54 chars)
ls -a $HOME
.Xdefaults .Xmodmap .Xresources .addressbook .addressbook.lu .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xserverrc.secure .xsession .xtalkrc
You get the idea...
Sure, wget has a command line option for my http proxy. But why isn't there a system-wide default that it uses?
Wait there is! But is it $HTTP-PROXY? Or $HTTPPROXY? Or $PROXY?
What's my default printers name? Yeah right it's probably $PRINTER, but then again, maybe not.
Sorry man, but I don't call that good. I call it ugly. Using an Apple, now that is pretty, and for a reason. Thinking about merging pretty (Apple) and powerful (Unix) sounds truly appealing to me.
The article was talking about user configuration as much as server configuration. I could live with seperate conf files for servers, but for user conf files it's just plain ugly.
Idempotent operation: Like MS software, wether you run it once or often, that doesn't make it any better.
This would be really nice for allowing configuration utilities to work on programs they've never even heard of. Imagine for a moment, that the developer of an application provides lots of useful information for each configuration option, such as the level of importance of an option, comments and descriptions, web links, the data type of the variables, etc. in a xml template file that comes with the application. The template could then be queried by whatever tool you're using and provided you have enough info linuxconf, web frontends, dialog apps, etc. could all build an interface by simply reading all those options from the template via some kind of library function.
Likewise, changes to the config could be passed through the library functions, get validated for correctness and then written to disk in whatever format you want. The level of functionality would be such that you could generate white space delimited files, xml configs, or whatever you want and because the template is descriptive enough, comments could be inserted/preserved for those editing with vi.
Now that I think about it, this really wouldn't a rewrite of existing applications, they could simply keep their existing formats and build the template file for other config utilities. Then, if at a later date they decide to drop their own config processing, they use the template driven library to do the processing work. That way backward compatibility could be maintained.
This does nothing to reduce the myriad different configs that you deal with when editing by hand, but it would give the authors a chance to move a more common format later on down the road. And I think it is more useful than trying to get everyone to switch to some unified format that appeases new users.
I have half a mind to try a limited version of this out for handling Apache virtual domains. And it's a lot more fun than hard-coding a parser into your frontend.
The current system for starters isn't too bad - the configuration files for important system tools are typically well documented (in man pages if nowhere else), and aren't too hard to edit in a text editor. Certainly there is a problem with the use of automated GUI tools for system configuration, but I can't really see why GUI tools are so important.
Consistency though would be a nice thing, if only so that as more programs are used and require configuration, we don't all have to learn more and more ad hoc configuration schemes. There is the potential for the current system to get well out of hand. Consistency is nice from an aesthetic point of view - ad hocery is rarely pretty.
Tools such as linuxconf or webmin don't help the problem, they just obscure it. Often badly! (Don't get me started on linuxconf, ugh!)
The earlier suggestions of XML, or a recognised subset of XML, together with XML schema to describe the formats, seem ideal as far as file formats go:
- It's standard and well-documented.
- There are a large number of parsers that work with a useful large subset of XML, for many platforms and languages.
- In a pinch, it's not hard to write a quick and dirty and correct-enough parser from scratch on an ad hoc basis, to parse your own particular XML-based configuration files.
- It's human editable (or should be, if used wisely).
- It is rich enough to encompass all the text-format configuration files currently in common use (under the Linux-based operating systems I know of at least).
The big problem of course is inertia: changing configuration files is a big change! Personally, I think the cost though would be worth it in the long term.The important thing to me is that there is no API specified as mandatory. While a standard API for accessing and manipulating configuration data would be nice, requiring it to be used will not only make adoption of a standard config format slower and harder, but will also limit software developers to the tools for which the API has an implementation. I'd go for:
I also agree with the earlier comment promoting the use of ~/etc over dot-files. Makes good sense! Again, it's only inertia that will make such a change difficult. Though if other changes are going through ... in for a penny, in for a pound!
Lastly, whatever scheme is adopted, it seems to me essential that there be some flexibility in where the configuration files are located. Standard places are important, but there must also be some way to say to an application that their config data is in /usr/local/etc, or in /opt/package-name/etc, or wherever. This is necessary for sane package isolation and management, especially if not all software on a system is maintained by someone with superuser priveleges.
Do you know what that means? "Based on NeXT" doesn't mean anything. NeXT was a company.
Mac OS X is based on OpenStep 4.2, which, itself, was based on NEXTSTEP 3.3. NEXTSTEP is a BSD operating system running on a modified version of the Mach microkernel. OpenStep is a API specification and a set of libraries that conforms to that API. OpenStep 4.2 (the operating system) is an implementation of those libraries on top of NEXTSTEP.
When Apple bought NeXT, they planned to build on top of OpenStep. They first produced Rhapsody for PPC and Rhapsody for Intel. They were the same OS running on two hardware platforms. On top of Rhapsody, Apple put the Blue Box, which was a Macintosh compatibility environment. At no time was there any need for a "BSD compatibility layer." It was all software running on top of BSD. Apple then killed Rhapsody for Intel (and the Yellow Box, but that's tangential.)
What was left was released as Mac OS Server.
Mac OS X 10.0 and Mac OS Server 10.0 (and further versions) are also BSD operating systems. They have the Cocoa (OpenStep) and Carbon libraries available, and the imaging system is called Aqua (replacement for Display PostScript.) At no point in any of this is there a need for any UNIX compatibility layer, as it is all real UNIX. The only compatibility environment necessary is for Mac OS 9 (Classic.) Only certain older applications (Carbon) can run natively on OS X, so for running non-Carbon apps, Mac OS 9 is run in a compatibility environment (similar, but not the same as VMWare.)
I hope that clarifies things.
There should be a moratorium on the use of the apostrophe.
Max V.
NeXTMail/MIME Mail welcome
This is a defeatist attitude. Did you even read the article? If MS or Apple can do it, we can do it, and we can do it better.
Now a GUI won't make people understand what they are doing or do the work for them (ever configure MS Exchange? That's a bitch....) but what it DOES do is make the configuration easier to navigate.
By using an XML based file format (as I proposed in a previous comment) you get the best of both worlds. The Apache config file is a close example of what I was thinking (it's not XML, but it is XML "like".)
An application would actually have 2 configuration files: one that actually contains the configuration data (like httpd.conf for apache) and the other to describe the options, help for the options, defaults, etc. to the configurator GUI. Both would be XML, would be extensible as hell, and provide a single tool for configuring any application, current or future.
As I mention in a previous post, a set of importers / exporters would provide a way to migrate until the various applications were updated to use the new format (sendmail may NEVER change...)
So you get what you want. Hell it would probably be better as you would no longer need to memorize all the differet quirks / rules for different applications's configuration language.
Why not use the standard tools we're already using today... autoconf, m4, automake, libtool.. and have them build a "standard" config file for us at configure/build time?
Probably because a lot of the configuration files which are editied by m4 aren't considered human readable.