On 03/15/2012 08:30, Rich Freeman wrote: > > 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.
I use a ton of the pl2303-based devices, too. Except I'm usually in Windows with them, so I just have to deal with Window's oddball way of renumbering them sometimes when I unplug one and plug it right back into the same USB slot (i.e., I lost COM11, and it's now COM14, which, ironically, is outside the range of TeraTerm) > 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. That, or udev making more of its functionality optional via its build system (does it use autotools and configure, I never looked, to be honest?). This would allow additional USE flags to be added to enable or disable additional functionality as needed. > 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. Funny, but as much as I am against Windows on a server, Windows Server is easier to turn off unneeded stuff than RHEL5 is. Windows Server comes with audio and TWAIN/IMAPI components disabled (or out right missing -- you have to add them back in through server manager). But try to remove features like sound, CD burning, various media players, text-to-speech, etc, from a fresh RHEL5 install, and you're in for a fight. It's not necessarily RHEL's fault, but more Gnome's fault because of the massive about of interdependency that you get with Gnome, and the fact RH chose to just not bother with it and build in a ton of stuff by default. Ditto for an install of OpenSolaris that I did. > 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). ZFS encourages creating volumes and filesystems en masse. Right down to a separate ZFS mount for each user's home directory under /home, and /home itself is a mount point. So yeah, Btrfs, ZFS, etc...get an FS like those two which not only encourage dozens of mount points, but which seamlessly hide all the dirty details from you (and the users), and issues like this will simply vanish into thin air. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
signature.asc
Description: OpenPGP digital signature
