On Thu, Mar 15, 2012 at 7:04 AM, Joshua Kinard <ku...@gentoo.org> wrote: > This does lead me to wonder if a light-weight udev could exist that lacks > half or more of the functionality of the current udev. I'll be honest, I've > only edited my udev rules file once, and that was only when I installed a > Sun Happy Meal quad ethernet card in which all four ports utilize the same > MAC address and udev doesn't handle this very gracefully (if I had Solaris, > I could edit the card's firmware and change this setting).
You know - I had a similar issue, but with a pair of PL2303 USB RS232 interfaces. That makes me wonder if there is a possible way to enhance udev to better handle situations where devices have no unique ID and thus tend to be difficult to access consistently across reboots. In my case I had to hack a rule so that I got a symlink if the device was in a specific USB slot. Use case is controlling tuners for mythtv. No doubt a simpler 80% solution could be created for udev, and likely it would be easier to cut down on its dependencies as a result. However, the other 20% of users will still need the more complete solution. Big distros that want to support lots of hardware with a one-size-fits-all configuration will just deploy that complete solution everywhere, which means that the only people maintaining the simple solution would be people who like to tailor each system. For most of the more enterprise-y OS providers (ie the ones with money to pay devs), one-size-fits-all is a lot more sustainable. You won't find an edition of MS Windows that works only on PCs without scanners and sound but uses 50MB less RAM, for example. Sure, we don't have the same constraints as the enterprise-y distros, but we do have the constraint that if we want to do things differently we will spend a lot of time patching what we could otherwise simply reuse as-is. I don't think that split filesystem installs are going away anytime soon. In fact, when btrfs is finally mature we might see them blossum. Using subvolumes you could have more granular snapshotting and mount options, while still maintaining a shared disk space pool (with granular quotas). If everything the distro is likely to mangle is in a few subvolumes you can reverts snapshots on those without losing changes in other subvolumes if you ran in production before deciding to revert. That gets you a lot more flexibility than a single snapshot on root - especially in terms of recovery time (you can still copy files between snapshots if you only snapshotted root - in fact with reflinks this is very fast). Rich
