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."

Comments

Isn't Linux getting there ?

[keshto]

These days, one can usually get away with the "./configure; make; make install; " routine and not need to worry so much. In any case, some of the charm of Linux does lie in your being able to tweak things. And Apple had the luxury of making one decision about software questions and implement them across all hardware.

Don't confuse Syntax and Standards

[osolemirnix]

I like the idea, such a tool would certainly be nice. Unfortunately the article only focuses on the Syntax part, the file format and access. I would think that is rather easy, use some kind of XML and you're already halfway there.

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?

Re:Don't confuse Syntax and Standards

[rbeattie]

I agree - though I think that XML is a GREAT idea for *nix to use, the format is just too flexible to just say "use XML" and leave it at that. There needs to be some sort of standard way of using XML as a registry so it's not a complete nightmare.

Other variations:

<DocumentRoot>

<setting name="someSetting">SettingValue</setting>

<someSetting>SettingValue</someSetting&gt ;

<someSection value="SettingName">settingValue</someSettin g>

<someSection>
<settings>
<settingGroupName>Test</settingGroupName& gt;
<setting name="SettingName" value="settingValue" />
</settings>
</someSection>

</DocumentRoot>

Etc. The variations on hierarchies and values are endless and is my main beef with XML. It sometimes can be too flexible and people who are using XML (especially newbies) make it overly complex or not suffieciently complex enough for expansion. In other words, this needs to be thought out.

But again, XML is a good idea. I hope it gets adopted as a general mechanism in *nix, but not in some random way...

-Russ

Other side to this

[larien]

This is something I think would help linux become more widely accepted, but there's more to it.

I was thinking this morning how I hadn't udpated my Apache server in a while, and wondering whether I should apt-get the latest version (Apache is kind of important for security, as it's the only open port on my system from the internet). However, I've done various tweaks to config files which would get overwritten if I accepted the Debian standard file, but I don't want to miss out on any new settings that could be important. I know I can do a diff, but that's effort I'd rather not have to go through.

This kind of situation is where a registry-like interface is useful; the install program just has to do a quick 'if-not-exist then add' to any new settings and leave the rest alone (or ask if you want an overwrite of all settings, with appropriate disclaimers).

This kind of thing is difficult to do in a flat file split into different sections (if there isn't a concept of sections, you can just tag the setting on), but trivial in a registry structure, especially when the tool (dpkg-upgrade/apt/rpm) has to handle all the different file formats. However, linux/Unix users would rebel en masse if the registry got inflicted on them (with damn good reason! I like being able to fix problems from single user mode using vi!), but some form of layer between the text file and settings may provide the best of both worlds (programmatic ease and editability). apt/dpkg/rpm could use the interface to add/modify settings without splatting your custom tweaks while still adding the new required settings.

Unfortunately, we're starting from a difficult point, with thousands of applications with many different requirements for their settings. Hopefully we can get some covergence over time.

Apple fixed it...

[Adnans]

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

gconf, LDAP anyone?

[DocSnyder]

"gconf" does exactly what the Freshmeat article describes: a unique way of storing configuration. Its frontend is abstracted from the backend which uses a hierarchy of small plain XML files per default but could also use a SQL database or a LDAP directory.

LDAP is nice on its own, too, with configuration being stored platform- and host-independently, as well as global, group-specific and user-specific settings. Netscape Roaming works this way.

I /like/ the Unix Configuration Nightmare

[Combuchan]

Why fix it? It's good right where it is.

I /like/ having daemons and programs having their own configuration file. I like having to be able to manually configure something and fix it myself, without having to fight with some meddling front-end. I like learning how configuration is done with each program. I like applying existing text editing and stream tools to work with configuration. This is the way it should be done, and this is why I like Unix far more than other OS's that aren't predominantly CLI-based.

Don't fix it. It's not broken. Things work great as they are now. It's not difficult if you want to learn how to do it. Your "Unix Configuration Nightmare" is actually an elegant symphony of applications, clients, daemons, sockets, and streams that is UNIX. Take it or leave it.
:)

And you know, when I was your age... wait, you get my point.

Re:I /like/ the Unix Configuration Nightmare

[bnenning]

*I* want to mess with those config files, rather than have some app(s) messing with one really important file.

You're right about the registry, but a better designed system can give you the best of both worlds. Mac OS X's plist files are human readable and writable, easily accessible via a standard API (1 line of code to get or set any property), and do not involve a single point of failure.

Install/configure

[autopr0n]

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.

Re:Install/configure

[lessthan0]

There is no simple, standard way to configure complex things. A nice GUI works fine if all you want to do is something simple, but when things get hard, you have to dig into the guts and really understand what is happening.

Now, using a standard syntax may hold some promise of making configuration a little easier, but the hard things will always be hard. No GUI will ever change that.

Also, text files are easier to manage remotely. Just give be ssh and vi and get out of my way :)

Re:Install/configure

[Cardhore]

You are exactly right. Have one or two files for the actual configuration (/etc/app.conf and $home/.app.conf), and one file that describes the configuration: its options, parameters, and help strings (perhaps in /lib/etc?). XML would probably be the buzzword to use here.

Think about it--with this method, you only need to write ONE gui configuration tool, for everything!

Re:Install/configure

[walt-sjc]

Configuring Win2000 as a file / print server that authenticates against a domain controller (or IS a domain controller) is TRIVIAL. Configuring a Linux box to do the same thing is a PAIN. This is the MOST common use for corporate servers.

You don't need regedit to do configure this unless you are REALLY into self-inflicted pain, and decide not to use the other tools. Regedit would be the same as vi in my example. It's a way to manually edit data. I am NOT describing regedit. You are thinking that my tool would be an XML browser that would basically manualy edit the first file I described. The second file is the key. It's the one that gives you all the smarts in the config tool such as whether to do radio buttons, check boxes, tabs, text entry, value validation, online help, etc. This is alot of the stuff that's hard-coded into so many different tools.

It's also the one that would define where in the scope of configuration of everything a particular task belongs. Obviously the schema, taxonomy, etc. need to be thought out, but this is a VERY doable project.

Needs Meta configuration file and config server

[Anonymous Coward]

I've been thinking about this for a while and definately think that there needs to be various elements to a Unix configuration system:

1) The concept of local and group configuration. There needs to be a Meta config file that specifies what individual users can and can't configure. So for instance, if a company wanted to allow users to configure their word processors however they wanted, exect that they couldn't make any changes to the dropdown menu of corporate document templates, that would be specified in the Meta file.

2) A configuration server. I see no reason why this couldn't work with http to deliver XML config files to individual workstations. The Meta files could reside on the server, the local files on the hard disc. You could imagine in this senario that in order to configure your machine all you would have to do is enter the appropriate URL and press go:

http://intranet.company.com/configs/standard.xml

Then you could have different configs for different types of staff, and supported and unsupported configs (from the point of view of IT support).

You could also perhaps have 'approved' config files for supported hardware.

Having this type of Meta config file also allow IT support to have a clear idea of all the hardware used.

I know that probably lots of people on Slashdot don't like the idea of IT support having control over the config of their machines, but big companies like it and if Linux is going to conquer the desktop then this is the type of tool that will help get it there.

Some similar thoughts

[Eloquence]

I had some similar thoughts when I posted this, which describes a system that would be capable of reading and writing various configuration files and at the same time try to establish a common configuration file standard. The idea is not new, a lot of similar attempts have already been made. I think the only way this can be successful is through massive collaboration in writing filters to support existing config formats. This means that the filters themselves have to be fairly simple (possibly even simpler than something like perl or awk, but everything should be supported), and that the configuration manager, as the Freshmeat author calls it, should offer direct access to the filter library so that you can easily add modules to support new programs.

There's lots of cool stuff you can do with standardized configuration files, and dynamically generated GUIs are only one part of it. But developers are not going to change their file formats unless there's a real push for a specific format. Thus, to establish any format, you first have to develop lots of filters to support legacy software. As the FM author correctly points out, such a system would make software configuration under *x potentially much easier than under Windows.

Finally, to all the hackers who fear that this will take away their file-meddling options: If properly implemented, it won't -- and if it does, it will not get accepted as a standard, exactly because of stubborn people like you :-)

What configuration nightmare?

[phaze3000]

As someone who has used Linux for some time, and also had the misfortune of using Windows (and doing those MCSE things for all my sins), I can honestly say that I don't think the configuration is the problem. The varying standards used by programs aren't a particular problem as long as there a decent comments in the file (and there usually) are.

The real issue is finding the configuration file; if you're using a distro you're not used to, then one often has to resort to using find. This is exactly what the Linux Standards Base was designed to avoid, and if all distros were to follow this model then I can't see that there is any real problem.

At the end of the day, we're not talking about things like setting background pictures in the window manager, we're talking about setting up mailservers, webservers and the like. If you're not cluefull enough to edit a text file then you're not cluefull enough to be put in charge of setting one of these servers up either.

Re:XML as a starting point perhaps?

[khuber]

In the writer's outline section he has a few bullet-points that scream "XML!"

I'd agree that XML is a good basis, but "XML" really doesn't provide much by itself. It's just a file format that is human readable. If you just use XML with a bunch of proprietary tags, your own XML language so to speak, you really don't gain much over the existing different syntax config files.

An automated tool has no clue what your ipaddress (or whatever) tag means at all. You need to provide additional context for tools to understand the semantics of the configuration data. To make configuration files understandable in a more intelligent sense, you need to either restrict the tags you use to your own configuration language, or you need to provide metadata of some sort.

Why is this intelligence necessary? Well there are all sorts of dependencies and relationships in configuration files. You might want a GUI to let you know if you change something that may break another setting, and so on. Plus ideally you would only allow legal values to be set. Data typing could be done with W3C XML Schema Definition Language, or RELAX NG schemas.

Which brings me to RDF, which I think would be better suited to this task than XML alone. If you use RDF (see http://www.w3.org/RDF/ ) you make it much easier to have a self-describing format that tools can do more intelligent things with than raw XML. While I don't think RDF, DAML+OIL, et al is enough to create a Semantic Web as Tim Berners-Lee is hoping, it _is_ a step in a higher-level direction that will support more intelligence in processing data.

Mozilla already uses RDF for various configuration files and I'm sure there are other applications that do too. Mozilla has a whole bunch of stuff about their RDF here.

XML is just a tree of "stuff" in human-readable format. RDF lets you set up properties and relationships in the data in a standardized way. I don't have a brilliant example to prove this to skeptics, but really it is a better way to represent a lot of types of data you want to be able to query. There are many knowledge bases, expert systems and other query engines already out there using RDF and even higher-level languages like DAML+OIL.

-Kevin

Two parser per application

[Anonymous Coward]

My (possible redundant) 2/100:

For every application we need two compilers/parsers: one from text to XML and one from XML to text. This way the programs can keep on using the old text config files (easy for programmers), and a nice config tool could modify the hiracical XML (easy for users).

I imagine that when the config tool is opened for some application the text config files are parsed with the text->XML parser, showed and modified via the config tool, and then parsed back into a text file.

It took this long?

[Ageless]

It took MacOS X for people to realize that this was a problem in UNIX? Please.

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 /etc/registry.conf. There is no reason it has to be binary.

Re:It took this long?

[evi1b0b]

It isn't very fun writing a bunch of dialogs, windows, buttons and such to make a nice configuration for a program.

It still might not be fun in OSX, but making interfaces is very easy because of the included dev tools and the cocoa application model.

A programmer of marginal skill can literally drag together a standard compliant UI in 5 minutes and have it work.

It's a little bit more than a lazy programmer issue. A rich, standardized library of Cocoa classes and dev tools that almost force oyu to do things "the right way" also contribute to better front ends on osx -- lets not forget the fact that the userbase probaly would not use an app alot if it didnt have a good interface.

Re:It seems you're missing the point

[thing12]

Webmin really doesn't do a good enough job. Really -- try using webmin against the latest version of most software and you'll be sorely disappointed. The problem is that the people who release the webmin modules are NOT the people who release the software that webmin is configuring.

What we need is exactly what the author is proposing. A generalized configuration system that works off meta data that the software developers supply.

• All the possible configuration options in logical groupings
• descriptions of each option
• default values
• validations on input values
• being able to label options as 'experimental', etc...
• and of course option dependencies - that is if this option is turned on, then enable these 5 other options.

To do it right you'd ultimately you'd probably need to have a very light scripting language with flow control and variables.

But the important thing is to get a workable standard in place, one that the majority of developers can rally around and will be happy to develop configuration scripts for their applications. Most developers wouldn't even have to change the way their application reads the config files - documenting everything in a form that this 'configuration manager' can use would be enough. It's already been too long - we shouldn't wait any longer to get this process moving forward.

Re:Mac OS X PLists

[Anonymous Coward]

I actually think this is a great way to go and am curious to know what can already be leveraged from Darwin. It appears that Core Foundation, a Darwin framework, contains the majority of the PList interfaces. Is Core Foundation portable under APSL?

I'd rather invest in one approach (that already works) rather than take the "I must create something pointlessly new" route. Plus - let's let's see Apple "contribute" to this one...

NOT a file-format, a parsing library

[camusatan]

The proposal isn't actually a bad one - we're talking about just a simple C library which can read, write, and parse configuration files using 'plug-in' stub libraries. That's what the author of the article is proposing. It strikes me as a good idea for several reasons:

• Certain configuration file-formats we're kinda 'stuck' with. For these files, we just have to write the plug-in which can read, write, and parse them. We don't have to re-write the application to comply with The New Way. The app doesn't need to change, or even be aware of the configuration library.
• A configuration utility written to use the library would be able to configure all applications which have the appropriate plug-in installed. So if someone writes a nice pretty GUI X-based app, it can configure everything. If someone writes a curses-based text menu app, it can configure everything. A web-based configuration app could also configure everything. Some config-apps could be oriented for gurus, and some could be designed for newbies.
• Eventually, applications themselves could use the library to read in their own preferences. Bonus - it's a little easier to write applications now.

All that being said, I foresee some 'gotchas' -

• The library system would need to not only know about configuration file formats, but some meta-configuration info such as - application X uses config-file format Y in location Z. Application X can be forced to reread its config by sending it a SIGHUP, it's process name is 'blah'.
• The design of the API for the main library has to be made veeeeeeery carefully. The number of different types of data that you'll have to deal with here are huge - we're not just talking 'integer, string, float' - but some relatively complex data structures like IP Address, or 'Firewall mapping' (two IP addresses, two ports, and a UDP/TCP choice).
• Configuration file formats that are unbelievably miserable and allow for the user to put script bits in them (isn't this why we all hate MS Word?) would be almost un-programmatically-configurable. Sendmail.cf comes to mind. It gets to the point, there, where the only thing that's ever going to understand the config file is the application itself.

This is a "Hard" problem.

[paj1234]

This is a non-trivial problem, and one I have some experience of (failing to deal) with.

My program is called "createusers". I wrote it because I wanted to make the following for 100s of new users in one go: user login, Apache home page, Samba account, PostgreSQL database, and MySQL database. I also did my best to make it extensible.

You can find my program here:
http://freshmeat.net/projects/createusers/
and here:
http://www.lfsp.org/

The fundamental problem I faced when writing createusers is there is no standard programmatically-accessible way of:

1) finding out what can be configured in each application

2) applying and undoing the changes.

Furthermore, I would like to make createusers programmatically-accessible. Unfortunately at present I cannot, because there is no standard way for me to let other programs know what facilities my program has, and no standard way for me to make them easily turn-off-and-on-able by other programs.

I received some add-on contributions to my program from other people. I noticed that their programs said "Have you enabled X in createusers.conf?", "Have you enabled Y in createusers.conf?", etc.

If I had standards-based turn-on-and-off-ability for my program, then my contributors' programs would have been able to do it for themselves. They would be able to easily check what things my program is set up to do; AND they would be equally able to change it.

This is a problem for people Much Smarter Than Me. If it is solved, then I promise to put the necessary bits in to my program so its setup can be easily, securely queried and changed by other programs.

Screw XML, use Python code

[Tony Hammitt]

We should use actual Python code as the configuration file format. It's callable directly from C, and by extension, all other languages. It's nice and clean. It supports heirarchial inclusion of other configuration files. It has easily readable comments. In short, it's the perfect configuration file specification language.

Wrong wrong wrong

[ttfkam]

The thing this article screamed was not "XML" but "API". Define the application programming interface for a library, and stop thinking that each application must directly access the native data

Yes, and the discussion went to the next step and started talking about possible APIs. The parsing of XML (DOM and SAX -- DOM for in-memory data structure and SAX for streaming access) are well understood and, most important, already done with innumerable tools already written.

XML Schema could not, for example, include primitive types for IP addresses (very common in config files), or validation constraints for integer values.

Wrong! Wrong! Wrong! You haven't read the spec and are obviously making assumptions based on what you've heard from others who haven't read the spec either. XML Schema allows not only the specification of integer, string, float, date, etc. values, but integer subsets (greater than and less than) and string patterns (through regular expressions). And RELAX-NG can use XML Schema's datatype support as well.

Do you have something that does validate IP addresses for example or were you just complaining about how one thing doesn't (even though it does) without showing anything that will solve the problem. If you say regular expressions, I must remind you that XML Schema supports regex matching of attributes and element data.

To date there are no (zero, zip, nada, nothing) fully compliant XML parsers.

Could you please enumerate these non-compliance issues? An encoding issue? Bugs in DOM or SAX support? What? I wonder about the vitrol of your argument without any specifics. Especially since I been using both parser that you mention (and a few others) without any noticeable issues associated with the standard. Any problem were usual to do with parser extensions to the standard which are fairly simple to avoid.

A vast number of parsers out there ignore the DTD, which means they cannot handle entities (which is a big issue).

You're right! That is a big issue. Unfortunately for your argument, it is not an issue with the leading parsers that you mentioned yourself: Xerces and MSXML. The default parser for Java (Crimson through JAXP), the default parser for Windows (MSXML), the default parser for Perl (XML::Parser I think...haven't used it yet) to name a few ALL handle entities. This is like saying that there are many web servers out there that don't support CGIs with the obvious intent of dissuading use of web servers.

A simple .ini-style line delimited key=value is the most readable and understandable (from a psychological viewpoint) configuration format.

I agree, but you're missing an important aspect here. INI files are usually one and at most two levels deep. They do not handle hierchical structures well at all! Let's look at a snippet from a default Apache configuration file.

# The following lines prevent .htaccess files from being viewed by
# Web clients. Since .htaccess files often contain authorization
# information, access is disallowed for security reasons. Comment
# these lines out if you want Web visitors to see the contents of
# .htaccess files. If you change the AccessFileName directive above,
# be sure to make the corresponding changes here.
#
# Also, folks tend to use names such as .htpasswd for password
# files, so this will protect those as well.
#
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>

What do we see? Hmmm... Because the key/value pair format doesn't allow hierarchy, they fell back to something that looks a bit...er...XML-like. And it isn't key=value, it's key[whitespace]value. Yet another issue: one file has the equal sign and others don't. I thought we were aiming for consistency? And what if the parameter is a message and that message has a newline character? A '\' at the end of each line? A '\n' where appropriate? These are problems that XML has solved.

And let's not forget Unicode support. We English speakers may have a hard-on for English, but can't you imagine a case where a program intended for a non-English speaking audience would want -- if not the names of the parameters themselves -- parameter values in alternate character sets than ISO-8859-1 (Latin1)? And before you rebut with UTF-8, do you want to write the UTF-8 translator? What about the other codesets? Are you strictly limiting to UTF-8? This is another area of XML parser that keep it simpler for the programmer. Transcoding is done for you and is most likely better implemented and supported than what you or I would come up with.

And when you have multiple "Files" definitions? Well, multiple blocks right? The "Order," "Deny," and "Satisfy" parameters are associated with the "Files" definition, yes? So why aren't you associating a group of "Files" definitions together? Because that would require further hierarchy? Would you end up with something like this?

<FilesDefinitions>
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>

...other Files definitions...
<FilesDefinitions>

Set up a relatively complex configuration where you have virtual hosts and those virtual hosts have behavior different from the default. What's that? You include them in tags by host? Tags that look somewhat like XML anyway you say? Imagine that!

And what about the comments? For some formats, the comment is the ';' character. For others it is the '#'. And none of which I am aware differentiate between implementation comments and actual directive comments. For example. the comment above describes the configuration directive so that any configuration editor could conceivably read in that info and display as help to the user (assuming that all comments were kept correctly before the directive and not after or on the same line). But what if you wanted to make comments about your specific installation. You are making comments so that others in your working group can see why you made certain changes to the config file, right? So how are they differentiated from the primary directive comments. This is the type of problem that XML namespaces are intended to solve -- a way of giving demarcation points to distinct pieces of (sometimes) unrelated data or simply the clean combination of multiple schemas so that your schema definition doe not bloat to immeasurable levels and different schemas can easily share with one another.

Something keeping back Linux/BSD/UNIX is the stubborn, 1337 coders who spent all day figuring out a config file that some joker on the net thought would be a keen config format but forgot to comment it. Let's face it, Apache is not the norm. Config parsers are a known problem with known solutions. Writing a config file parser is not the primary focus for most programmers out there. The config file is a necessary evil to them. Let's make it easier and just say, here's your DOM interface. It's well documented, works well for the limited dataset with which you a working (config files are usually less than 50K), will handle any configuration organizational type you want (hierarchical, flat, etc.) and will save you the time of writing a parser yourself.

Have a nice day.

I don't want to troll here

[Anonymous Coward]

But if the Linux community even't can't agree on common interoperability for business apps (like OLE) between two major desktops, a thing which is important to push linux on the desktop, nor any commong config file format (xml, unix config way, sendmail, etc...), how can they agree on a common config scheme?

Avoiding configuration

[Animats]

Putting a GUI front end on a mess merely results in a less understandable mess. The problem needs to be fixed. Here's how:

• Avoid configuration wherever possible. If something can be discovered, it shouldn't have to be configured. This applies to most pathnames. Searching directory trees is faster than it used to be. Long-term, a database of where stuff is is needed. Note that Microsoft is going that way.
• The PATH approach to program finding has to go. It leads to everything being in a small number of /bin directories. Each installed program needs to be in a separate directory subtree. /bin directories should consist only of links.
• Separate preferences from configuration. Individual user preferences should be disposable; if they're missing, the defaults apply. The old MacOS worked that way.
• There are several categories of programs. Ordinary applications should be installed in a separate directory subtree for each program. The subtrees should be organized something like the Windows approach of "program files/vendor name/app name/". For ordinary applications, no interaction is allowed between apps at install time, and a standard installer should enforce this. That way, installing A can't mess up B.
• Programs that aren't "ordinary applications" should be given some identifying name, so users are warned that they may mess things up. This will discourage unnecessary tweaking during installs. All games, for example, should be ordinary applications. Programs that mess up other programs' installs should require more privileges to install than those that don't.
• Hardware should be recognized via discovery, period. Support for hardware that can't be discovered should be dropped.

We will now hear from all the people who insist that "they have to do wierd thing X because it's (traditional) (k00l) (needed to support their 386 machine)". They're wrong. Someone needs to be a hardass and fix this thing.

XML is not the solution.

[Zygo]

I think that people who moan that Unix should be more like Windows or Mac don't really understand Unix, or Windows, or Mac. XML is part of the problem--people who think XML is the solution, or even neutral, are suffering from a specific kind of delusion which I'll cover in more detail later.

Advocates of auto-detection instead of manual configuration I'll deal with right now: Applications in certain problem domains require explicit human-supplied configuration data. This is unavoidable in any application that has to implement some choice of policy, especially security policy. There are some things you can't ever autodetect, so if you can't configure the application, then you need many different applications, each hard-wired for one possible desirable configuration. Certainly a lot of things that should be auto-detected are not, but auto-detection will not eliminate the configuration problem.

Windows and Mac are platforms controlled by a single vendor. That vendor has a _lot_ of influence over how applications are designed for that platform. When the vendor designs and implements the platform, the vendor will (intentionally or otherwise) reward applications with an architecture consistent with the vendor's design, and penalize those that don't. Applications tend to comply with the vendor architecture because the cost of non-compliance is greater than the cost of compliance.

Unix is not a platform controlled by a single vendor. Heck, it's not even a platform; it's a bunch of little standards that were chosen arbitrarily and stitched together. Linux, FreeBSD, SysV, BSD, Solaris, QNX, HP/UX, etc. are not Unix platforms--they are platforms compatible with Unix, implementing parts of the SUS, ANSI, and POSIX standards, with varying degrees of completeness and success. As such, there is no reward for making an application's architecture consistent with the OS vendor's design; contrariwise, there is a compelling reward for an OS vendor to make an OS architecture consistent with a desirable class of application.

The difference is critical for understanding the configuration file nightmares of both kinds of platform. Windows has a really awful configuration mechanism that nobody would ever use if they weren't compelled to; however, certain parts of Windows are only conveniently accessible via this configuration file format, easy (if not reliable) methods to access the format are provided to all developers and available on all end-user machines, and the configuration schema does not define a lot of policy to get in the way of extensions (need new schema? Add a new DLL!). The Mac has a different architecture and mechanism with the same consequences.

On the other hand, applications that run on Unix are, in whole or in part, designed for "other" systems. Applications that were designed and written exclusively on Unix-like platform X eventually get ported to some other Unix-like platform Y--those that don't tend to be eventually replaced by similar applications that do. When this happens, the resulting application is an alien on both platforms. The application must find everything it needs on each target platform, or it must bring with it those things that are missing from some target platforms. This means that the application will have translation or interpretation layers (all C apps have at least one translation layer in the C compiler) and replacements for missing functionality in the target platform.

Now for the delusions. New code written in a language with link-level compatibility with a free, small, fast, easy to use in code, portable, robust configuration mechanism library will have no problems. Note that the status quo is already as free, small, fast, easy to use in code, portable, and robust as it needs to be for applications that already use it, so alternatives which are not all of these do not merit discussion.

However, there are constraints imposed on this hypothetical library by legacy code:

1. It would have to be already installed or available on all Unix-like systems with bindings to all Unix-like languages, which rules out nearly everything invented after 1978. Otherwise, every application (and language!) must bring either a copy of the library or their own code. Strangely enough, "open file," "read text line," and "lexically analyze this string" primitives are implemented in nearly all Unix-like languages, and interactive text file editors are shipped on nearly all Unix-like systems...
2. It would have to be as small and fast as fgets+scanf, or a lex+yacc parser, otherwise it will hurt performance or have a large footprint, and people who care about performance or size won't use it. XML can't do this unless you drop the i18n and character entity and encoding support--at which point it's not really XML any more.
3. It will have to use small ASCII text files for persistent storage, otherwise you have to implement and force everyone to use either your own editing mechanism (aka "a control panel DLL"), or you implement and force everyone to use replacements for Unix filesystem-crawling tools which allow you to selectively access the data (aka "the registry and regedit", or "replacements for cvs, vi, find and grep")--both of which violate the "once and only once" rule since these facilities exist already in Unix and they are used for this purpose.
4. It will have to be used directly by the actual applications--otherwise you violate the "once and only once" rule by having either two configuration files and two applications (the real application, and a configuration application), or two configuration file handling mechanisms in one application (for old-style and new-style config files).

It might be possible, given overwhelming demand, to convince maintainers of significant mature legacy code to adopt the new configuration mechanism, if the XML-based mechanism is more widely ported and better debugged than their own configuration-management code. Good luck, and be prepared to do the work yourself many, many times over until you either change their minds, or they leave the project and you're stuck maintaining the code by default.

Note that other standardization initiatives, like FHS or the LSB, involve relatively superficial changes which application maintainers were probably willing to make anyway. The FHS and LSB ask application maintainers to change the parameters to a few system calls without affecting the architecture of any part of the application or the semantics of its operation. For example, the application may open()s a file, but after the FHS is implemented that file has a different name. Both names are constant strings, the file is still opened for reading, and it still has the same contents with the same syntax and semantics. A one-line change and a recompile brings the application into compliance, and in an emergency, a symlink will make the application work.

Other initiatives, such as DNS and PAM, are usually facilities that are not intrinsic to applications. Host name resolution or user access verification involve resources shared by many applications, and there is a real technical penalty for non-compliance.

Changing the way applications handle configuration is a large architectural change--you're asking people to replace open(), read(), close(), and some code which is intrinsic to the application with new functions that have different semantics, and may even have to be called at different times. Expect resistance.

The only hope of this ever happening in real life is for a Linux distributor to decide to implement it, and contribute the work to achieve it. Said vendor will have to hack and slash their way through hundreds if not thousands of packages to bring them into compliance. Once all of that is done, all the upstream package maintainers will have to integrate the changes--or all the other Linux vendors will have to repeat the hack-and-slash job.