Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Integrated color management with colord
Posted Sep 29, 2011 0:53 UTC (Thu) by rpkelly (guest, #74224)
Posted Sep 29, 2011 7:49 UTC (Thu) by michaeljt (subscriber, #39183)
I thought (but may be wrong) that DBus was able to start helper applications in response to queries rather than requiring the helpers to be already running as daemons.
Posted Sep 29, 2011 11:32 UTC (Thu) by rpkelly (guest, #74224)
Still, I thought the original commenter was suggesting no helper application at all, but instead a shared library. Correct me if I'm wrong, though.
Posted Sep 29, 2011 2:13 UTC (Thu) by malcolmt (guest, #65441)
There are always going to be people who want text files only removed from their cold dead hands as a data format, but it's 2011 already and we collectively have a few decades of experience in how fragile text file editing can be (and well-known locations tend to be different locations even amongst different Linux distributions). This is a exceedingly minimal extra layer with some quite large benefits. I'm encouraged to see it happening more and more.
Posted Sep 29, 2011 3:12 UTC (Thu) by pabs (subscriber, #43278)
Posted Sep 29, 2011 3:32 UTC (Thu) by jimparis (subscriber, #38647)
Posted Oct 6, 2011 11:37 UTC (Thu) by Wol (guest, #4433)
If system config files go in etc, then personal configs should go in ~/etc or ~/.etc!
Not that mirroring the system setup in ~/ is a good idea, but it's a lot better than the current free-for-all!
User config location
Posted Oct 8, 2011 17:23 UTC (Sat) by grawity (guest, #80596)
Posted Sep 29, 2011 7:50 UTC (Thu) by michaeljt (subscriber, #39183)
Surely using DBus for querying the data addresses that.
Posted Sep 29, 2011 12:27 UTC (Thu) by dmk (subscriber, #50141)
Posted Oct 4, 2011 10:39 UTC (Tue) by juliank (subscriber, #45896)
If you designed the library correctly, there would not be any difference in the complexity of changing the format. If you expose sqlite3 types in your library, you did something wrong.
Posted Sep 29, 2011 20:54 UTC (Thu) by kleptog (subscriber, #1183)
Posted Oct 5, 2011 7:34 UTC (Wed) by cmccabe (guest, #60281)
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.
Posted Oct 6, 2011 13:44 UTC (Thu) by n8willis (editor, #43041)
The SQLite db stores the *mappings* between devices and the various profiles assigned to them (including the fallback ones). By storing them in a database, the daemon can perform real queries on the various properties of said mappings, in addition to just a trivial (and static) DeviceX:ProfileY.
Posted Oct 7, 2011 9:21 UTC (Fri) by dgm (subscriber, #49227)
1. All files are subject to corruption. A text file is "fixable". A database file is not. It's gone. Forever. You cannot even read it.
2. Many times database formats are used for speed. The only problem is that for sequential reading, a text file is far faster than any database. Go ahead, test it.
> but it's 2011 already
Posted Nov 14, 2011 20:25 UTC (Mon) by job (guest, #670)
It's both easier and more robust than loading it from an sqlite driver, and you're going to stuff it in your own memory structure anyway.
Posted Sep 29, 2011 11:32 UTC (Thu) by cortana (subscriber, #24596)
Posted Sep 29, 2011 12:49 UTC (Thu) by dlang (✭ supporter ✭, #313)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds