Linux

How to fix configuration anarchy on the Linux desktop

Marco Fioretti brings up one of the perennially pesky issues of the Linux desktop -- multiple configuration files for very similar programs. See if you agree with his proposed solution to configuration anarchy.

Since (more or less) 1997, every year has been "the Year of the Articles about the Year of the Linux Desktop." The starting point, which you know very well, is some variation of "Linux will never be a desktop for the masses until it does x..." with, of course, very different values of "x" for every Linux user.

Relax! I am not going to inflict on you my own definition of "x". Not today at least. However, Jack Wallen's post here at TechRepublic about the "10 ways the Linux community can fix the mess on the desktop" brought back to the surface of my brain something that has been seriously bugging me for a long time.

I see something pretty messy in all Linux desktops that is much more general than Linux: it's something missing in the way that many FOSS desktop applications are developed. Jack goes close to it in point #8 of his post.

Which applications should be installed by default in a Linux desktop? OpenOffice, LibreOffice or Calligra? Evolution, mutt or Thunderbird? Firefox, Chrome or Konqueror? Nautilus or Dolphin? digiKam or f-spot? Blackbox or IceWM? Emacs, VI, Kate or gedit?

Personally, I don't care that much if the programs I prefer aren't in the system menus or aren't installed by default. I know FOSS enough both to install without help almost all the software I need, and to avoid like the plague most discussions on these topics. I care even less if some program is a KDE or GNOME one. What really bothers me though is: why there is no cooperation about configuration files?

I mean, having 20 wildly different mail clients, 10 newsreaders, seven text editors, five browsers, two or three office suites, etc., is really great, no question. People are different, choice is good and so on, or so they say (more on this later). The point is that these are all "Free as in Freedom" programs - it shouldn't be unnecessarily difficult for users to try something different, right?

So my question is: why isn't there only one configuration file for each class of these programs -- that is for each task?

Take email, for example: no matter what client you use to read and write it, you'll have at least one set of data that are always the same: From and Reply-To addresses, IMAP and SMTP servers, password, content of signature, which apps should be used to open attachments with a certain extension, etc. Why can't there be ONE .mail client file that stores all those settings?

What about browsing? In most cases, the cookies, bookmarks, proxy, default search engine and predefined values for HTML forms that a user needs won't change if he or she decides to switch to another browser, or simply to give it a try before dinner. Why can't there be ONE .bookmark file and/or ONE .browser file that stores all those settings in one common format?

Why can't there be one .audioclient file that says where all music files are located, the default sorting order for songs...okay, I hope you get the idea by now: why can't FOSS users configure tasks once and for all, instead of configuring manually all the many different choices for each task, even when they have already typed many of those data in another window of the same computer?

Sure, in some cases we can "export" and then "import" such data manually with a few clicks, without typing all of them again by hand. That's how, for example, you can exchange bookmarks between Firefox and Konqueror. However, at least in "Free as in Freedom" software, it's a dumb thing to do anyway. Why should there be any need to import and export such data in the first place?

All these task-wide configuration files could be plain text files with a format like this, in which settings valid for all browsers are in variable with generic names, and settings that only make sense with some application have as prefix the name of that application:

BOOKMARK_FILE=/path/to/bookmark_file

USE_PROXY=Y

PROXY_URL=http://myHTTPproxy.example.com

FIREFOX_ON_THE_FLY_TRANSLATION_PLUGIN=...  #

Taking browsers as examples, with files like these you could use Firefox for a month, then switch to Konqueror in one second for another month, then go back to Firefox or try three other different browsers in no time: all the configuration changes made in each moment (new cookies, bookmarks etc...) would always show up in all those browsers.

Plain text files, that are much simpler to back up and carry far less dependencies than any database, would be more than adequate for this scenario. In the real world, the risk that two different applications corrupt such files by writing to them at the same time would be almost non-existent. I'll bet that today, if a user is staring in the same moment at the configuration interfaces of Firefox and Konqueror, almost surely the reason is the very problem files like these would solve: the need to re-enter some settings manually. Please note that this approach wouldn't forbid developers to use at run time whatever file or internal database they're using today. All I ask is something in a standard format that each client reads at startup and writes (if necessary) before quitting.

Besides saving user time, there may be another reason for task-wide configuration files: rumor has it that non-geeks are scared by choice and, by extension, by FOSS desktops with their too many choices. If such people didn't have to reconfigure from scratch all the installed programs, until they find the one they like best for each task, maybe they would be less scared. What do you think?

About

Marco Fioretti is a freelance writer and teacher whose work focuses on the impact of open digital technologies on education, ethics, civil rights, and environmental issues.

33 comments
victoria2403
victoria2403

You said exactly what I was thinking in this post and I wanted to say thanks. vet in Dallas dermatologists in Raleigh antiques Long Beach builders Tucson personal trainer in Phoenix

zat_6832
zat_6832

A program called Linuxconfig I think was the name, and it sought to be what the author seeks to find: a way to 'fix' configuration anarchy. Available as both gui and command line. It was really what it said it was. Deprecated and gone as far as I know. Was missed. Part of the reason why I left RH. Found Mepis, but that is another story. Perhaps it can be revived?

K_Green
K_Green

Good idea! It would also make standardization for certain corporate settings easier to implement. Got a new machine? Just point it to the corporate config standards files. Boom! Your email client's configured, your basic intranet bookmarks are set, etc. SMTP & POP gateways changing? No problem ... the appropriate team makes a global change to the settings file and everyone flips over at once.

raceboyer
raceboyer

Many linux programs use the .config folder for their configuration. If we could start with just one location for configuration files that would be a triumph.

MichaelADeBose
MichaelADeBose

Static accounts info for email and any other data that makes sense should be available system wide, in a write once but highly philandering system wide approach. I'd love to be able to drop this one 'super' form in a folder on each of the OSes I run and aside from telling each email program what identity to use, just be ready to rock. We repeatedly type what our preferred fonts are and what our names are in email programs online and in each OS we use. Why not just create a standard 'super' form, that contains "environmental" settings, file owner settings, font preferences, volume settings (please) as well as account info, every time you create a set of logins or email accounts under a different identity, you'd be asked where to append this data or should you create a new identity under which to file the new info. The file should also have a public part, a second file with no privileges, that could be uploaded to blogs and web sites automatically fills in user information that we all type in like name, job title, byline and what else. From that point on, you don't update each of these profiles when you come up with a new tagline, you just update your 'super' form. If you host it somewhere, your presence is updated everywhere from that one 'secondary' form. You could even be queried for the file while doing an install of a new or OS. Me, not only do I enter my own data but I end up doing it for the people I love as well. Something like this, Sweet! This may sound like a lot, but when I look at how many freaking times I type my name in a year or the settings I have to type in every time I virtualize or multiboot an OS I'm trying out. This is needed. The Unix/Linux world is resplendent with philosophical and technical differences but at the same time there is the ability to come together in a way to decide what matters. This matters because OpenID, 1Password and Mozilla (identities) have been trying to solve this in limited venues for some time, but the one and only place to truly solve this is on the hard drive. 1Password, or OpenID or whoever competes in this space, and they can continue to compete because they are competing not on personal info which never changes, but on methodology. I don't know how many have read this article, but I hope you get the pulpit somehow. While you're there, please ask if we can standardize for the most part on 1 kernel, why can't we make our differences about the OS and not the boot sector.

mfioretti
mfioretti

Thanks to you all for your interest. Both compliments and criticism show that there is something here that we should all look at in more detail. I plan to write a follow-up to this post in a couple of weeks, taking into account all the feedback I get with this one. Please keep the suggestions (and the criticism) going!

pjy405
pjy405

I can see the advantage of having unified config files for the user and the ability to switch between mail clients (for instance)... but I don't think this will ever happen. First, this would have to be agreed and implemented upstream by the makers of these mail clients. Second, 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 or other developers to perform changes and implement new features. Some times, we see standards emerge, such as XDG or the LSB... or even open formats which come with specifications such as the ones used by Open/LibreOffice. Maybe one day we'll see Microsoft, Apple, Mozilla, Opera and Google sit at a table and agree on some open standards for their bookmarks, favorites etc... but for now they're more interested in competing with each others, not in making it easy for people to switch amongst web browsers.

Orodreth
Orodreth

I like the differences. Knoppix provides almost the complete desktop on one CD that's flexible and surprisingly quick. Regardless of distro sometimes applications you're working Kaffiene stops working, switching to an installed alternative VLC works. There's the software manager APT vs Zypp etc.

WDMilner
WDMilner

Ok, I'll play devil's advocate for a minute. Scenario: I regularly use browser X, e-mail Y and news reader Z. They are all nicely configured in Desktop-settings.conf I decide to try e-mail client A, which requires some slightly different configuration options. Which of course are written to the unified desktop-configuration.conf. If I decide I don't like e-mail client A and remove it, I have to reconfigure my original e-mail client as the desktop config file is now wrong. A backup you say? but what if I changed something else while I was experimenting with e-mail client A that I want to retain? Changing clients and programs that use similar setting will create collisions. (similar to scenario above). Additionally when programs are used and then discarded, over time the file grows to contain increasing numbers of orphan settings. This happens all too often with windows registries. And removing a program can't just delete the settings it uses indiscriminately as they may be needed for something else. While it may seem old fashioned, and to many counter-intuitive, having individual configuration files for individual applications/programs can be a secure and efficient way to manage them.

nustada
nustada

The reason is because technological evolution works, and a diverse ecosystem is a healthy ecosystem. The best compromise is for developers to make conversion plugins.

todd_dsm
todd_dsm

@Spitfire_Sysopas This is a good idea. Push-back due to it's non-existence is not a reason to discard an idea. When you see a solution that does not yet exist and it has merit, it's usually referred to as "innovation". I hate to be a "should-ist" but, you should question this kind of thinking before breaking out the toilet paper. RE: config files, et al: Configuration files should be read into memory when a program starts. Anything else (holding and locking them), generally, seems like a poor design choice. As far as syncing bookmarks between browsers, xmarks has already solved this by syncing them in the cloud. It should be less of a hassle to sync them locally. It's just a matter of standardization+will. Files used for interoperability are usually called xml - so there's the standardization; now for the will to use it(?). @Marco Fioretti @tncoles / @framefritti if more people had your attitude more things would get done in this world. Some people have a difficult time seeing a solution that does not yet exist. It starts with an idea and builds momentum based on its merrit. Developers don't come up with ALL the ideas - that's what RFEs are for. Kudos gentlemen. But here's the real hard part, for example... It's been many years since the first browser; the browser wars (suprisingly) continue. I think you'll find innovation is the key to the problem. I'll explain: I make Firefox and you make Chromium. We both have a base set of requirements that users now expect, the difference is really in the implementation. But, I might perform a release with bug fixes and optimizations. While you, smart devil that you are, have found some revolutionary new feature that nobody asked for, but they now want and need. In this scenario a single configuration file would probably need some additional configuration parameters. In a greater sense this might have to be put past a 'steering committee' or perhaps there could be rules put in place for adding new parameters. Then, if you need the parameters your program can call to it, if you don't - then you don't. In the case of a steering committee, you would be giving up your hand, and letting your secret go a bit earlier than you would probably like. But, the first time someone uses it the secret is out. Anyway, something to think about. Again, I think this is a great idea. It would help us to see how serious we actually are about standardization.

r_bigcat
r_bigcat

OH! Another some one who wants to talk about it. Hey, I have a great idea. Why don't you be quiet and rattle off some code and really show us how. Talk is cheap, be a sneaker and just do it!

framefritti
framefritti

I like the idea of having a "global" configuration description. It is reasonable to assume that some configuration choices will not depend on the specific tool used, but on the application "class" (i.e. e-mail, word processing, web browsing, ...). However, it is also true that different tools can have different options and a single size (configuration file) could not fit them all. I see a two-level, hierarchical structure: one class-wide configuration file for the "high-level" parameters common to all the applications of a given class, and tool-specific configuration files that MAY override the choices done in the class-wide configuration. For example, if you use two newsgroup reader and you want to use each reader with a different server (for whatever reason), you can omit the "newsgroup server" from the class-wide file and specify it only in the tool-specific configuration. Note that the class-wide configuration file needs not to be Linux-specific, if the format is general enough, the same file can be reused with other OSes, since the choices expressed in the class-wide file would depend only on the application class (e-mail, web browsing) and not on the specific tool. If you put your file under a share system (e.g. Dropbox) you can configure your environment just once and bring with you your configuration choices. (I currently work with 5 different PCs, some with Linux, some with Windows and I would like this type of feature) About the synchronization problem: it is true that one must take care of this, but it seems to me that it is like many other synchronization problems. Just lock the file before writing it and check the file every 10 seconds to verify if it changed since the last time you read it. If it changed, read it again. If the file is not huge and the syntax is not excessively complex, your user will never notice the slow down caused by the configuration reload. (Of course, pay attention not to rewrite the options that were overridden by the tool-specific configuration file)

Willy the JOAT
Willy the JOAT

I can't argue with the premise or the concept, but it doesn't go far enough. What we really need is an accepted, user-friendly (modular and graphical) configuration interface which is aware of the settings (unique as well as common) for various x-purposed applications. New versions would update (or at least notify) the configurator's database. Why do the user's really need to know the gory details, just to write a letter to Grandma?

radarop
radarop

Living in an enviroment where I deal with a lot of "users" I have learned one absolute truism about the average computer owner/user. They do not want to have to learn something new just to use their computer. They want what used to be referred to load and go. Just turn it on and make it work. If the run of the mill user has to change settings, update stuff, etc. they want almost no part of it. I truly believe this attitude is what stops linux and other operating systems from beating out windows in the everyday world. Anything that makes linux more "load and go" will attract more average users to it. And I wouldn't mind haveing that info stored in one place for the programs to find it. I know that I switch from Firefox to chrome to ... I don't really want to re-enter all the data nor import bookmarks etc. I agree that a common repository for data that several common programs want and isn't usually going to change much would be great. Anything andd I do mean anything that makes linux easier for the average user to just turn on their computer and start doing stuff without them having to take time and brain bytes to do will help linux overcome the reticence to use it I see in so many of my friends, family and co-workers .

Spitfire_Sysop
Spitfire_Sysop

Why would it suddenly be a good idea now? Personally, I use each program for different things. 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 When I open up Thunderbird I don't want to see my work e-mail. The same is true for browsing. I may use a different web browser for checking my bank account than I do for other on-line activities. I will keep wildly different security settings on these different browsers because of this. I don't want things getting mixed up with my banking browser so I need it's settings separate. The bottom line is that what you are suggesting doesn't exist in Windows or Mac OSX either. I know that Linux is often the pioneer of great new ideas but this isn't one of them. Why don't you just write an app that syncronizes your settings? Most people won't use it because they only have one of each program and don't notice a need for moving their settings.

Willy the JOAT
Willy the JOAT

Perhaps such a buy-in from all the biggies for such a mechanism isn't needed. It only needs one to present a well-thought-out scheme that the user's will find makes life easier. Provided that the mechanism was well-documented and clearly non-proprietary and extensible to other programs and packages, it could be leveraged into a competitive advantage. That seems to have MS's idea with the Win Registry, but its complexity and arcane nature makes it a disaster. One thought would be to run the database as a service which returns its information in a useful way, such as in an XML stream. The client could parse that and use the information in any convenient way. Internally, the database would be hierarchically organised, with each value tagged as "Default", or associated with a particular set of clients. Perhaps the request would identify the client, request a set of parameters, and both the default (if any) and the client-specific values for the parameters would be returned. The per-client values could be removed in one swell foop, instead of the search and more-or-less destroy technique to remove metastasized parameters from the Win registry or trying to guess which config files belong to which application. Many other mechanisms are possible, but I think the idea has merit.

Xiferdiferous
Xiferdiferous

Yeah, I can understand that sentiment. I'm not operating system coder, but I did cut my teeth on spreadsheets as far back as Lotus 1A and and r-Base and developed some very useful stuff for my employers and as a result for everyone else in the company that needed to get on-board with the platform. As more and more staff became accustomed to using my developments, over time awestruck appreciation instead turned to criticisms and demands for more instant gratification for more and more, faster and faster turn around on projects. I too got soured on writing up more and more, faster and faster spreadsheet and database projects for the overly demanding under appreciating lazy masses. So I got smarter and redeployed my assets for more money elsewhere.... It is true, as more of the masses get on board with a platform, these new experts can really try one's mettle. It was difficult to get used to the idea that I just wasn't going to be adored anymore for my then cutting edge implementation of desktop technology. Now in my 60's what was then cutting edge is no longer; anyone who has ever read a Dummies book can do what I used to do to earn my living and is getting reflected in wages. I drive a bus for a living now and am enjoying life more and more.... and now enjoying Linux too.... If I haven't said so before.... I think all Linux coders and writers are doing great things.

CharlieSpencer
CharlieSpencer

To be effective, the development community as a whole would have to agree to utilize such a concept.

tncoles
tncoles

So perhaps what we need is pluggable *configuration* modules (PCM) a system (ala PAM) that provides a common api for the applications to talk to and modules can be written to handle the back-end configuration files (whatever or where-ever they may be). It *may* then be possible to have thunderbird (for example) request its configuration from PCM by asking for a either a tbird config or a mail config. It would of course have to be able to handle individual user preferences and not just system wide - perhaps the PCM module would make reference to a file in the users home dir. This wouldn't need to be limited to X applications either.

Xiferdiferous
Xiferdiferous

I like this view of Load 'n Go and it is this concept is what finally got me to change over to Linux. It was those ISO's that allowed for me to Load 'n Go with any and all the flavors. I'm more akin to the average computer user but also analytical enough to get interested in learning how stuff works under the hood. Somewhere in customizing an installation choices should be considered where common configurations can be shared with other similar applications. By now Linux writer's of apps are sophisticated enough to program commonality amongst common apps and still allow for differentiation that separates their product offering from anyone else. Now if Quickbooks would write their product for Linux, I'd reformat my Window's pc hard drive in a nano-instant. I'd have no need for any Windows computer. (except for my clients needs - but I'd port them over in two nano-instants.)

NickNielsen
NickNielsen

Because I'm a hardware tech whose application development expertise died with Foxbase Pro 2.5. There's nothing wrong with the idea. All it would take for implementation is to ask the user a question at install time: "Would you like to use the global [email/browser/office/whatever] settings? Y/N" If yes, access the global mail/browser/office/whatever config file and go. If no, then the user is presented with the current install method that requires each application be configured individually.

CharlieSpencer
CharlieSpencer

I'd love to see this on Windows. It would certainly have made life much easier a couple of years ago when I was test driving six or eight different personal finance apps. Ditto file managers and virtual desktop managers. Why isn't this a good idea? How would implementing it bring any harm? This information has to be stored someplace; why not a common format? Have a newly installed program look for the common file; have the install or configuration ask if you want to use it, and override if desired.

daengbo
daengbo

You've just basically described GSettings with a DConf backend.

Spitfire_Sysop
Spitfire_Sysop

In this shared bookmark example what happens when I open Chrome and FireFox at the same time and they both use the same settings file? When I bookmark a new page in FireFox what happens to Chrome? You can't actually have the same file open twice. Does it make copies like MS Office? Then how do you manage syncronizing? Do you develop this new settings manager as a background process in the OS? I see this causing more problems than it solves.

Spitfire_Sysop
Spitfire_Sysop

This is why they exist; because they are different. They offer different features thus different settings. By making a standard you cripple diversity which is huge in the Linux world. If all of these finance apps were the same then there wouldn't be much competition and you wouldn't need to test drive them! I am all for things like a standard export format, like CSV, so that you can easily migrate your data from one program to another. The settings are usually the big differentiating factor. P.S. In Windows there is a standard place to file all the settings called the registry and it is a mess. Programs rarely share registry settings because if one program changed a setting it could break your other program...

seanferd
seanferd

And for all the advantages of sqlite, now there are no easily dealt with html/txt files for bookmarks and such. (But it's simple to install this extension or the engine itself. Yet also annoying and a bit arcane and who knows when development on the extension will suddenly stop and you can't use the extension for some DBs in a running instance of the browser....) I suppose it is better than some options, but what is wrong with flat text files (or formatted text or html) in the first place? Concurrent access could be addressed differently, but seeing as some of my favorite browsers have already gone sqlite, I don't suppose there is any point in mentioning this except no way, no replacing all config files with a DB for Linux. If a distro wants to do that, fine. No thanks on this being a new feature of the kernel and standards. Text, please.

MarkGyver
MarkGyver

Fortunately, there is already a much more advanced storage method that has decent concurrent access support and is actually already used by both Firefox and Chrome. It's called SQLite and is basically an embedded SQL database format. The code is public domain and it's small enough to statically compile it into a program with very little overhead.

CharlieSpencer
CharlieSpencer

and only COBOL and FORTRAN when I was. You're asking implementation details. Temporarily ignore the 'How to'; what do you think of the idea itself?

Willy the JOAT
Willy the JOAT

Ah, the caching to improve performance myth raises its ugly head!

pgit
pgit

Saying a text file config, which is read once at application startup, is anything like the windows registry is like comparing apples to flying giant tortoises with a supreme disliking toward equally large, bipedal reptiles. huh? Exactly... I heartily second this idea, I've been saying something like this for years. There is no reason it can't be done, same as there's no reason there can't be a standardized default file system. (and paths) There have been a number of times using the best (or only) available tutorial required an extra step of correcting paths to files, for commands or simply to know where they are, eg for backups. Fedora might have configs in /etc and a working directory in /var, whereas the same app in Mandriva has configs under /opt and the document root is in /usr... Try running a few dozen commands off a fedora tutorial on a Mandriva system... It's worse with these config files. And it appears to be getting worse yet. KDE for example now breaks out parts of configs and has some under ~/.config, others under ~/.local and of course a slew of them under ~/.kde4/... in numerous sub-locations. Just finding things is a PITA, then what you have found may not contain the variable you are looking for. The KDE team and Mandriva are working together to integrate Mandriva's most excellent Mandriva Control Center into the KDE systemsettings interface. (I'd prefer to see it go the other way around, so mcc could still be used with gnome or other DE) Good move. Now if we can convince them to take a look at this idea, broader standardization of basic, common configs, we just might get to that "year of the Linux desktop" and mean it for once.

CharlieSpencer
CharlieSpencer

I think I replied that use of such a storage area wouldn't be mandatory. Unlike the Windows registry, there's no way to enforce it. It's not the apps that are the same, just that they'd look first to a defined storage area for some common information on initial configuration. With financial apps, why re-enter the same name, address, account number, list of payees, list of transaction types, etc? Just because the Windows registry can't implement this idea properly doesn't mean it can be done right by someone else.

Editor's Picks