Integrated color management with colord

I have experience debugging a large software suite with a couple of daemons that communicated using CORBA. I also have debugged the combination of NetworkManager, the desktop manager, wpa_supplicant, and the kernel. In both cases, using remote procedure calls made it a lot harder to figure out what was going on.

If you're using D-Bus or CORBA, you'll need special tools just to observe the messages that are going over the wire. Sure, they're out there, but you'll have to install them and learn them. Then you'll need to get debug versions of all the relevant programs, and make sure that you've restarted all the daemons involved. After that, you'll need some way of correlating log messages between the various programs. If you're lucky, the programs will include timestamps in their log messages that you can correlate with the timestamps in the d-bus output. If you're not, well, you'll have to hack the source.

When you've got asynchronous communication going on, you may very well have race conditions that appear and disappear in a frustrating way.

In contrast, if you were debugging an application that simply read a text file using a shared library, you could probably get pretty far with just "strace <program-name>."

Similarly, UNIX programs should really consider using text files to store configuration. Text files fit in with the rest of the UNIX system-- they can be grepped, rewritten with sed and awk, and so forth. They can be versioned with git or svn, and they take up very little space. If you search on Google, odds are that you will find helpful people who have pasted their text configuration files for you to copy.

However, if the program stores its configuration in, for example, sqlite, most people will not know how to get access to the information in that file, let alone modify it. Yes, in a perfect world, they would be proficient in how to use the SQL language, the application's schema, and the dumper tools, but ours is not a perfect world.

There are some cases where D-Bus and SQL databases are the right solution. But programmers need to stop to think that just because they can, doesn't mean they should.