>
> This workflow is currently utilized by many automated services and is
> fairly robust. It is also secure -- Continuum's business depends on it.
>
There is no guarantee this is secure and certainly without some kind of contract in place (which could be as simple as someone going and registering with them) it definitely does not count as secure.
> It also polutes the git tree and a make clean / make dist clean does not
>> clear this up.
>>
>
> Everything it does is put inside $AMBERHOME/miniconda. This is hardly
> polluting. We can have make clean/make distclean clear this stuff out
> quite easily ("make clean" should definitely not touch this, but there's an
> argument to be made that distclean should). I can expand on why I *didn't*
> have distclean remove this if you want my explanation.
>
make clean probably should not remove this but make distclean should in my opinion. Ultimately I'd expect make distclean to take me back to effectively immediately after I untarred things.
> In my opinion we really really really should not be depending on tons of
>> external libraries and the configure script in AMBER should definitely NOT
>> be connecting to any external sites EXCEPT ambermd.org.
>>
>
> You're certainly entitled to your opinion, but mine is that this stance is
> rather arbitrarily purist. The reason I say it's arbitrary is because it
> would be easy to simply host those files on ambermd.org -- but why not take
> advantage of their (i.e., Continuum's) better web infrastructure (more
> reliable web service, more bandwidth, faster connection to more areas, ...
> etc.)?
>
It is definitely not arbitrarily purist. It is perfectly reasonable and widely used business practice. This is connecting to something and downloading without the users permission. This is very bad practice (and possible illegal in a number of countries). We should be very careful here. We can't assume that an internet connection is available for installing AMBER and even if it is we can't be downloading something that requires us to rely on a third party. Yum install blah etc is fine because it uses repositories that users explicitly agreed to when installing the operating system. Note most major companies host their own repositories internally and require there installations to have passed internal security audits. This circumvents that and would raise a lot of red flags at any pharma company for example that uses AMBER.
In my opinion this is dangerous and unreliable road to go down that could expose us to a number of potential problems, both practical and legal.
> It also should not be doing this for a configure that does not involve an
>> AMBERTools build.
>>
>
> I've fixed this. I've also improved the CUDA configure so it doesn't try
> to configure (an unused) FFTW-3.
>
> A couple other notes -- it seems you're using an outdated version of the
> tree. configure no longer goes off and does this on its own. It's smarter
> about figuring out when it should do this and then asking for permission.
I haven't updated in a few days because I am traveling with extremely limited internet connectivity - the other problem I ran across here when tethered to my phone it tried to download a ton of stuff just from me running ./configure. If the new version asks for permission this better - although I'd hope that the description of what it is going to do and what is involved (and what it involves the user explicitly consenting to) should be very clear.
> It's also circumvented entirely by specifying a python to use with Amber.
Can it not be the reverse? This would seem much better to me. E.g. test for all different combinations etc and only if it finds something that doesn't work does it then ask one to specify the python to use or offers to download miniconda? E.g. I have no idea which python's are on my machine, where they are etc. I expect it to just find python in the path and work. This is how it should be by default unless I explicitly specify otherwise.
> For instance, if you do `./configure --with-python /usr/bin/python gnu`, it
> will simply use /usr/bin/python and never attempt to build its own.
Why can't we just do 'which python' and have that be the default and then you can override it if you are an expert user?
> I will also fix this to not be a fatal issue when connectivity is a problem.
>
That's a definite requirement since there are may systems where people install AMBER that are not freely connected to the outside world. Granted rarely in academia, where things tend to be loose security wise, but in a commercial environment this is the norm.
All the best
Ross
/\
\/
|\oss Walker
---------------------------------------------------------
| Associate Research Professor |
| San Diego Supercomputer Center |
| Adjunct Associate Professor |
| Dept. of Chemistry and Biochemistry |
| University of California San Diego |
| NVIDIA Fellow |
|
http://www.rosswalker.co.uk |
http://www.wmd-lab.org |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
---------------------------------------------------------
Note: Electronic Mail is not secure, has no guarantee of delivery, may not be read every day, and should not be used for urgent or sensitive issues.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Jan 28 2016 - 08:00:04 PST
