Answering readers and critics on Linux configuration anarchy

Marco Fioretti got some great feedback on his post about Linux configuration anarchy -- so much so that he offers some thanks and a few rebuttals on the topic.

A couple of weeks ago I wrote about the Linux configuration anarchy that bothers me and got a lot of feedback. As promised, here is a follow-up to thank the readers who like the general idea, and even extended it, and also to answer some critics and issues raised by that post.

This is about configuration data, not interfaces. And no LinuxConf, thanks!

A couple of readers said, more or less, "I remember a program called Linuxconfig or something like that, and it sought to be what the author seeks to find: a way to 'fix' configuration anarchy...It was really what it said it was."

Marco: Sorry, but first of all, Linuxconf never was what I am suggesting. Secondly, the implementation was bad! I only suggest that configuration files for all programs of the same class should have the same format. Linuxconf offered a unified interface: when you told Linuxconf what you wanted, it would rewrite all the involved configuration files, each with its own format. Then, at the next reboot, some init scripts would rewrite some parameters, and things wouldn't work. There's a reason why Linuxconf disappeared (even if it wasn't all its own fault) and, personally, I am happy it did. This doesn't mean that a unified configuration interface is intrinsically a bad idea, it's just a separate issue.

Configuration anarchy is either intrinsically right or unavoidable, because every program is different

This is the thesis behind comments like:

  • [different programs] offer different features thus different settings. By making a standard you cripple diversity which is huge in the Linux world
  • There's a reason each software follows its own configuration, the developer can implement changes more easily, structure the data the way he sees fit and doesn't rely on compatibility issues...
  • It's easy to logically separate programs for different tasks. For example: Personal e-mail could all be in Thunderbird. My work e-mail comes in Evolution
Marco: Please (re)read the whole article. I never said that there should be only one program per task or a unified configuration interface. My idea may be wrong, but surely it doesn't cripple any diversity. How does asking that I only have to type some data once and have it saved on disk in only one place limit the developers' freedom to change how their software works, or its user interface?

Besides, I explicitly stated how to manage application-specific settings and, as other readers pointed out (thanks!), that a single program may still have custom settings for common options. For example, a 'KONQUEROR_HTTP_PROXY=' line in the .browser_conf file would tell Konqueror to use that proxy instead of the one specified by the generic 'HTTP_PROXY=' option.

Finally, well written FOSS programs have always had the possibility to use a whole alternative configuration file, even if just for one single session. Such a feature is very convenient for reasons that have nothing to do with my proposal, so if it's missing, that's a problem regardless of my ramblings.

Text and only text, please

Some readers, concerned by data corruption caused by concurrent write access of two or more programs to the same file, suggested to use databases ("especially SQLite, since it's already used by both Firefox and Chrome"). Others said plain text files are okay if one adds some elaborated locking scheme.

Marco: No databases, please! Compared to databases, text files are easier to edit manually or via scripts, much simpler to back up, much more portable (even across multiple OSes!) and much more likely to be adopted. The set of FOSS programs that should avoid configuration anarchy is much bigger than Firefox and Chrome, and most of them do not use SQLite today. Convincing their developers to change the syntax of something they almost always already write to plain text files is immensely easier than making them add any other dependency to their code. Besides, file locking could be much simpler than most readers think. See next point.

The solution is a setting synchronization/conversion tool. And since this is Open Source, do it yourself!

Some people asked questions like:

  • Why don't you just write an app that synchronizes your settings?
  • Why don't you be quiet and rattle off some code and really show us how?
Marco: The first reason why I won't write myself a "synchronization app" is that I am not asking for anything of that sort. I am suggesting that certain configuration files should have the same format. The reason why I not only won't write patches to make that happen inside other people's code, but that a I also actively discourage people from doing it, is that it doesn't make sense.

There are much better uses for good programmers than making them learn internal parts of many unrelated applications written by somebody else and then systematically patch each release of all those applications. Synchronization? It is necessary in many cases, but at this level (that is "how should a bookmark or the name of an SMTP server be stored on disk?") it is really silly to create the need for it.

If the developers of some software want to continue to keep all its configuration also in its current custom format, because it's much better for performance, robustness and what not at run time, that's okay for me -- as long as I also get only one plain text file to back up per task, and I get to set ("how" is a different topic) each of its options only once!

It isn't mandatory to cancel what already exists or write a unified interface in order to give end users the benefits of a common configuration file. It would be enough to add to each program one routine that loads that file at start up if it changed after last session, and writes it if needed right before quitting. Only the original developers of each program could do this in a sustainable way, with the smallest possible effort.

Of course, this would work only if those developers agreed on the format of the plain text files. Paraphrasing another reader, this proposal could "help us to see how serious they actually are about standardization."