On Mon, May 28, 2007 at 03:34:22AM -0400, Bill Nottingham wrote: > José Matos (jamatos@xxxxxxxx) said: > > On Monday 28 May 2007 05:41:04 Bill Nottingham wrote: > > > So, my reading of this is 'larger phys/chem institutions are > > > crazy and don't understand sane systems management'. Am I reading > > > this wrong? > > > > Don't downplay their efforts, most of their problems run for months and they > > are very carefull about the results, after all is their reputation that is at > > stake. :-) > > Yes, but... describing a situation where results are run on whatever > machine of whatever OS, with whatever random libs happen to be in > /usr/local? Doesnt sound like an environment that intends to be replicable, > or easily managed. What happens when a disk goes out? Or someone replaces > one of those libraries? Nothing, because the code was statically linked. That's where you get deterministic, non-environment dependent results from, no matter what the environment looks like (in sensible limits, of course): Either a too old distro (running FC6 builds on FC5), a cross-distro build (running FC6 builds on SLES clusters), or in general missing libs, old libs, old compilers, broken parts under /usr/local and so on. With a static build, you don't care and have the same results as in your local tests. To be completely fair, the real number crunchers like clustered systems or mpp systems do have more careful setups with no self-built debris lying in /usr/local (but old or missing libs nonetheless). But the users developing the code do need to build/install bits under their /usr/local. Therefore submitting a job sometimes means you have to statically link your code, do a final test on your system, upload it and queue it into whatever queueing system is supported. Or you apply for a sysadmin to build the required libs for you, so you don't have to statically link and you find out that your contract expires before all parts are in place. Not to speak about asking the admin a year later to upgrade the libs. -- Axel.Thimm at ATrpms.net
Attachment:
pgpWySRRTWVRK.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
