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.
i too was under the impression that it was based upon FreeBSD and Mach rather than netBSD, quite consideribly different, to start with they even tried to poach Linus and get him writing their kernel, but he refused so they went with the FreeBSD project leader instead, [sarcasm]and haven't they been so helpfull to opensource as a whole with OSX and Darwin.....?[/sarcasm]
Software Freedom Day!.
In an interview of an IBM director, I asked why their then current OS had no GUI (when Windows was chipping at the userbase). Reply:
Mindsets change - at the speed at which glass flows
This is not a signature.
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)
maybe the community should agree about common human interface or at least about a common configuration file interface so a kde/gnome/... app can be written using the data for providing an easy setup tool.
i think it would be a good addition to the linux standard base
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
What you appear to be describing is NetInfo, a Windows-registry-like component that more or less functions mostly in place of certain typical UNIX config files. It's a NEXTStep legacy, but, unlike the Registry, it somewhat sidesteps an otherwise nightmarish way to handle OS configuration. And, it doesn't scare the bejeezus out of you when you look at it. The Netinfo Manager application will be used commonly by most experienced UNIX users to reactivate the root process, which Apple switches off in OS X for security/safety reasons.
OS X is based on FreeBSD, albeit an older version. It's pretty damned nice for an older kernel.
Vos teneo officium eram periculosus ut vos recipero is.
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.
Name a piece of current (not ISA etc), statndard (not some home built/unknown vendor PCI card) PC harware, other than the motherboard or the processor and it will most likely work on Mac OS X. It may fall back on a generic type (missing some features) but it will most likely work. Macs support: PC133 RAM, ATA hard disks, PCI cards, AGP cards, VGA monitors, USB, IEEE 1394 (FireWire), etc. I think that would be more than 50 types of hardware. Don't confuse the fact that the iMacs are closed with other Mac hardware. The G4 Towers won awards for how easy they are to open up and upgrade. There's a large handle on the side of the case that you pull and that side of the computer lowers down with the motherboard attached to it, giving easy access to all components.
Could it be that Macs are easy to configure because Apple engineers are clever?
Note: I'm ignoring the fact that this article is about software not hardware configuration.
Check out some more myth debunking.
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.
The BIG problem with Linux/UNIX config programs is that they aren't stateless. Programs that try to keep their own versions of all the config files (ahem... linuxconf) get all freaked out if you go in and change a file by hand the manly way (with vi, not emacs). Webmin (I think) does not try to do this, so it appears to work better. If someone were to write a NON-STATE-KEEPING tool then it has a much better chance of working nicely.
-- I am. Therefore, I think!
Speaking as a longtime UNIX (BSDi and Linux) user who's been running a production Mac OS X server for about six months, I can say that OS X is a breath of fresh air, simply for the Server Admin tool.
It's actually faster and easier to use the GUI to add, configure, and start a virtual web server than it was the old way (edit httpd.conf, apachectl restart). Some settings cannot yet be controlled using the GUI, but for those, I can easily edit the same old config file, the same way I've been maintaing Apache for years.
To be fair, Apple hasn't implemented everything in a way that's immediately intuitive (i.e. system startup script locations). And the documentation of some things (like system startup scripts) is nonexistent. But things improve with every release, and already I prefer maintaining OS X server to a linux box. (This was not the case until last fall's 10.1 release, though.) -Alex
The X resource database is a great configuration database - it is perfect for user preferences - and you could even use the same file format for non-graphical programs, too.
.INI files...).
Irritatingly, both KDE and GNOME ignore the XRDB and go off and implement their own half-assed systems (in KDE's case, reminiscent of Win3.1
Motif, Tk and Xaw applications all honour XRDB configuration -which is great!
Want all applications to use a font?
*font: Arial
Want a certain application to use a font?
*Xterm*font: Courier
Want a certain button in a certain application to use a particular background colour (n.b. this is an immaginary one)
*moogybrowza*toolbar*backbutton*bgcolor: cyan
Fire up editres and play with Netscape 4 some time...
- yes, that's right, Xaw and Motif applications are dynamically "themeable", at run-time, have been for years! Qt and Gtk suck on this front compared to widget sets that use the XRDB.
It's a true database, not just a single-tree structure like xml, so it's pretty damn powerful - and is STILL human-editable text, yet
can easily be wrapped in a GUI.
It's a bit like the Windows Registry, but DONE RIGHT...
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.