[Beowulf] A press release
Many of your questions may have already been answered in earlier discussions or in the FAQ. The search results page will indicate current discussions as well as past list serves, articles, and papers.
Prentice Bisbal prentice at ias.eduThu Jul 3 08:10:50 PDT 2008
- Previous message: [Beowulf] A press release
- Next message: [Beowulf] A press release
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tim Cutts wrote: > > On 3 Jul 2008, at 2:38 pm, Prentice Bisbal wrote: > >> Here's another reason to use tarballs: I have /usr/local shared to all >> my systems with with NFS. > > Heh. Your view of local is different from mine. On my systems > /usr/local is local to the individual system. We do have NFS mounted > software of the kind you describe, but we stopped putting it in > /usr/local because users got confused thinking it was really local to > the machine. We now have a separate automounted /software directory for > all that stuff. See my other post. The FHS says it's okay for both /opt and /usr/local to be shared over NFS, but I wouldn't do both. For me /usr/local = NFS share, /opt = local to machine. Why do users need to know what's local and what isn't? All that matters is they need to know the path to a file. (It's logical location, and not it's physical location). That's the beauty of the Unix filesystem hierarchy: everything is arranged logically, not physically. No drive letters, etc. In a properly configured environment, things should just work for the users. I'm speaking in general terms, for HPC where disk or network I/O can be significant factors physical location is important. But that's usually for *data*, not the binary running, which is usually read once, and stays in memory for the remainder of it's execution. -- Prentice
- Previous message: [Beowulf] A press release
- Next message: [Beowulf] A press release
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
