== Fedora 19 and the search for volume management

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 Fedora16EnvironmentBits]]) 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 FedoraHardCustomEnvironments]], which is another aspect of
this.)