Fedora 19 and the search for volume management

July 18, 2013

Every so often I am unhappily reminded of one of the hidden problems of modern Linux systems. Today's direct problem is that when I upgraded my office machine to Fedora 19, automatic mounting of USB memory keys and so on stopped working because gnome-fallback-mount-helper (which is what I've used since Fedora 16) has now disappeared, just like every one of its predecessors. The real core problem is that a great deal of modern Linux is essentially opaque.

After all, I know that Gnome, Cinnamon, MATE Desktop, XFCE, LXDE, and KDE (at least) all implement volume management somehow, through something. If modern Linux was a relatively transparent environment it would be possible for me to actually find out what bit of one of the desktop environments did this volume management and then just run it by hand; I could probably find at least one of these that did it with a basically standalone program. As is now, though, while some of these may actually have such a program it appears all but impossible to actually find it due to the programs, components, and interconnections all being relatively opaque.

This is all the more frustrating because such a program is actually pretty trivial. The hard work is done by system daemons that broadcast device information over DBus (and can be asked to mount the devices). All that automatic volume management actually needs is a little program that listens for announcements of appropriate new devices showing up and then tells the system 'yes please mount that'.

(There are reasonable reasons why such a little program isn't good enough for actual desktop environments and so probably doesn't exist.)

DBus itself is part of this opacity issue because it has become a central IPC mechanism without particularly good observability. While you can monitor some amount of DBus traffic, as far as I know there is no way to tap into it to find out (for example) which process is sending certain sorts of messages to a standard system bus address. If there was such a monitoring method you could snoop on an existing desktop environment to find out who was sending the 'please mount' DBus messages. This might not give me a distinct standalone program I could run, but at least I'd have a better idea of how the environment was actually doing all of this magic.

(Possibly I am behind the times and all of this stuff is nicely documented somewhere, along with writeups of standard modular tools that people use to support the various magic desktop operations that happen today. I would actually like that to be the case even if it would make this entry a bit foolish.)

(I've written before about the difficulty of custom environments on modern Linux, which is another aspect of this.)

Written on 18 July 2013.
« Do specific HTTP error codes actually matter?
Thinking about the security issues in HTTP 403 versus 404 errors »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Jul 18 00:41:15 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.