On Thu, 2011-07-28 at 08:54 -0400, Genes MailLists wrote: > On 07/28/2011 08:41 AM, Genes MailLists wrote: > > On 07/28/2011 07:53 AM, Bryn M. Reeves wrote: > >> On 07/28/2011 12:46 PM, Genes MailLists wrote: > > > >>> This is a good point. Especially when you start on a 64 bit box and > >>> login to a 32 bit (or other arch) - bin now makes now sense at all. You > >>> need arch specific bins (bin, bin64 etc). > >> > >> Currently Fedora only separates out the /lib* directories in multilib > >> installations - you'll find a mix of 32 and 64 bit binaries in the system binary > >> paths on these systems. > >> > > > > which is fine for a 'system' which is 64 bit and may support 32 bit as > > well - its not fine for a 'user' who logs in to a 32 bit machine from a > > 64 bit machine and now his binaries wont work. > > > In the same way as an NFS mounted /usr/local/bin which only had 64 bit > binaries would not be a lot of use on a 32 bit machine. It can be dealth > with of course - what I've seen in this case, is either 2 different > mounts or making both available and having the PATH adjust as needed. > Add to that different architectures and the PATH way gets nasty fast. My > preference is for the machine to mount the right one under /usr/local > (or /usr/share or whatever. My understanding of the history of /usr/local's nomenclature is that it was intended to be "local" to the machine (and thus not NFS mounted). Your point applies just as well to /usr; but I think the intent was for NFS-mounted /usr to accommodate a single point of installation in homogeneous environments; supporting heterogeneous environments just wasn't the point. My impression is that NFS-mounted /usr is pretty uncommon these days--and perhaps unheard-of using Linux. NFS-mounted $HOME, however, continues to be relatively common and certainly warrants consideration. -- Braden McDaniel <braden@xxxxxxxxxxxxx> -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
