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(a)endoframe.com>