Hi Robert,


> It says, among other things, that udev can be configured to handle
> automounting. That's nice, but since systemd has polluted udev beyond
> repair, I'm wondering if Devuan can be set up to handle it better, perhaps
> with vdev. Or is there a better way?
>
>
Have you considered pmount(1)? Or, were you looking for something more
automated?

Related to vdev, one feature in my pipeline is to create a "vdevd-user"
daemon to replace udisks/udisks2 and upower. It would behave almost the
same as the system-wide vdevd, but with the following key differences:
* it would get started as part of a user's login session,
* it would run under the user's permissions,
* it would watch the contents of /dev/ with inotify (Linux) or kqueue
(BSD), instead of listen to the kernel for hotplug events.

The system vdevd would populate /dev/ per usual, and your vdevd-user
instance would run your user-defined actions when device files and metadata
appear or disappear. One such action could be to run pmount(1) to mount
(or umount) removable media. Another action might be to change your CPU
performance profile and backlight on your laptop if your AC power state
changes (NB: while there are no device files for ACPI devices, vdevd
receives events about them and records them to /dev/metadata/, which
vdevd-user could watch and act on).

It's worth pointing out that vdevd-user could easily work with udevd, mdev,
or a static dev as well--the device manager only needs to create the
requisite files for vdevd-user to consume. There's no need for a dedicated
dbus interface, client library, or init system.

-Jude