On Sep 5, 2009, at 3:00 AM, Jeff Squyres wrote:
> On Sep 4, 2009, at 5:47 PM, Sylvain Jeaugey wrote:
>> Understood. So, let's say that we're only implementing a hurdle to
>> discourage users from doing things wrong. I guess the efficiency of
>> will reside in the message displayed to the user ("You are about to
>> the entire machine and you will be fined if you try to circumvent
>> this in
>> any way").
>> Maybe the warning message should be set by administrators
>> ($OMPI/.../no-override.txt). It would certainly be more efficient :)
> Ralph is certainly right: there is no way that we can prevent users
> -- even those with the best of intentions -- from circumventing the
> system when they perceive the system not working they way they want
> it to (such is the nature of open source). So this functionality is
> just adding another hurdle towards trying to help prevent that
> behavior. It does help in [ISV] applications where OMPI is
> statically linked to the app -- in that case, the user *won't* be
> able to just replace the system OMPI with their own.
> That being said, it does seem like the best-functioning hurdle would
> be to print a site-specific message when users try to override priv
> params ("Bob the sysadmin set a parameter for this system that you
> tried to override. See http://internal/why-ompi-is-set-this-way.hml
> for an explanation of OMPI site-wide settings"). This might give
> well-intentioned users a clue as to *why* the system is not
> functioning the way that they expect, potentially educating them and
> deterring circumventing the system.
I really like this addition - if users just see something not work,
they will tend to believe something is broken and try to develop
workarounds. Explaining -why- it is restricted will help reduce that
> I think that's the best that we can do.
> Jeff Squyres
> devel mailing list