VMD-L Mailing List

From: Johannes Schauer (j.schauer_at_email.de)
Date: Mon Oct 07 2013 - 02:11:37 CDT

Hi John,

thanks for your reply :)

Quoting John Stone (2013-09-17 18:05:14)
> There are several motivations here. One of the major ones is that our
> funding agencies require us to report the number of registered VMD users.
> You'll note that things are done similarly for other software tools in our
> field like Chimera, PMV, AMBER, NAMD, and many others. They too likely have
> to report their user numbers to their funding agencies.

Yes indeed. It is unfortunately a very common reason why software in that field
can't make it into Debian main :(

> Another issue is that VMD users expect help and support with getting VMD
> running on their systems, and we find it much easier to deal with supporting
> builds of VMD we made ourselves, rather than having to track the behavior of
> binaries produced by other people without our knowledge. On the one hand, it
> would be nice to have VMD in every Linux distribution, but on the other it
> would greatly multiply the number of build scenarios we would have to be
> aware of. This comes up with strange bugs like the problems that certain
> versions of Tcl/Tk have with SCIM (internationalized input), issues with
> certain versions of OpenGL headers, CUDA versions, and other library
> dependencies that have nothing to do with the code in VMD itself.

It is the task of the distribution maintainers to make sure that the upstream
software (vmd in this case) works flawlessly within their chosen operating
system. To that end, bug reports of Debian users should be sent to the Debian
bug tracker first. If users do not do that and report to upstream instead, then
upstream will usually refer them to the bugtracker of their distribution. It is
then the task of the Debian maintainer to find out whether it is a Debian
specific bug or a bug in the upstream software itself and to make sure that it
gets fixed in his distribution or even upstream.

> If we allowed redistribution, we could no longer count on people using the
> "best" library version (from the point of view of VMD specifically). They
> would instead be compiling VMD dynamically against "whatever" version of
> these library dependencies the Linux distribution preferred. And for closed
> source things like CUDA, OptiX, and/or other libraries, the users of those
> Linux distributions would likely be missing those features of VMD by default,
> which I think is an undesirable outcome. I have yet to see a Linux distro
> that ships pre-compiled binaries that depend on anything that's closed
> source. I would hate to see a default build of VMD that disabled CUDA
> acceleration for example... I don't know of any open source OpenCL driver,
> so that too is the same issue. I would rather that users get full-featured
> builds of VMD with all of these components enabled, even if that means that
> they have to get them from us, or worst case, by compiling themselves from
> source.

Maybe you are talking about something different but I did build vmd with cuda
(which is also in Debian but non-free of course [1]).

[1] http://packages.debian.org/sid/nvidia-cuda-toolkit

I planned to (but didnt implement yet) build vmd twice. Once with and once
without cuda and then ship a binary package with each of them. The default
right now is to build with cuda support enabled. For people who cannot make use
of cuda, I wanted to offer a version without it so that they do not need the
huge bunch of dependencies that comes with the Debian non-free cuda packages.

> > Next, I want to present a number of patches which I'm currently applying to
> > vmd. Maybe they can be considered to be integrated in the next vmd release.
> > The patches are by me and Michael Banck and others of the debichem team.
>
> I appreciate your patches, and I will start looking at them later this
> week after I get past some deadlines. Hopefully we can accomodate many
> of your suggestions, and in cases where we cannot, maybe we can find a
> compromise that simplifies things specifically for the Debian community.

Well the biggest blocker is of course the missing redistribability of vmd which
makes it impossible to just use Debian's package manager. To that end I came up
with the following Python script:

--%<---------------------------------------------------------------------------
import mechanize
from lxml import etree
import sys
from subprocess import call

br = mechanize.Browser()

br.open("http://www.ks.uiuc.edu/Development/Download/download.cgi?UserID=&AccessCode=&ArchiveID=1190")
def handler(n):
    try: return "UserName" in n and "Password" in n
    except: return False
br.select_form(predicate=handler)
br["UserName"] = sys.argv[1]
br["Password"] = sys.argv[2]
resp = br.submit()

def handler(n):
    try: return "LicenseText" in n
    except: return False
br.select_form(predicate=handler)
print br["LicenseText"]

def handler(n):
    try: return "AgreeToLicense" in n
    except: return False
br.select_form(predicate=handler)

resp = br.submit("AgreeToLicense")

tree = etree.fromstring(resp.read(), etree.HTMLParser())
call(["wget", "http://www.ks.uiuc.edu"+tree.xpath("//meta[@http-equiv='refresh']/@content")[0][6:]])
-->%---------------------------------------------------------------------------

That script automates what one would otherwise have do in the browser to
download vmd. To execute it, the username and password have to be given on the
commandline. The dependency on the mechanize Python module can easily be
dropped by more manual parsing of the returned html and after the license text
is printed, the user should be asked whether or not he agrees with it instead
of just continuing.

It would be possible to create a package that contains above script and uses it
to automatically retrieve the latest vmd version, given an existing username
and password. This is similar to what is currently done for Adobe Flash as
Adobe also forbids redistribution of its binary.

Would this be an acceptable solution, given that the vmd license will likely
not change any time in the foreseeable future?

cheers, josch