DataWiki

Moving software around: space/time i.e. portability across platforms (“space”) and archival (“time”)

(aka “in vivo”)

Classical distros DebianBlends, special package managers nixos

Quoth idyll

"There is a deeper principle at work here: the distinction between a user and a maker.
A user merely wants to take your software and run with it; a maker wants to probe,
remix, and mash up your software. To maximize the benefit of our scientific software,
we should be enabling makers, not users. To do anything else limits the use of our
software to our own imagination, rather than enabling serendipity. And wouldn't that
be a shame?"

You can devote effort to keeping the software portable. This adds a whole new layer of complexity to the undertaking. You have to cater for

• program portably in the first place (not always trivial)
• build/deployment machinery (automake; CMake; ant; whatever
• debug portability bugs

Possible to distribute that effort whenever other prospective users might be interested in (parts of) your software

Practical example: OS distributions (e.g. Debian, RedHat SuSE & their relatives)

Licenses matter here much: People will tend to re-use your software (and improve it: “keep it alive”) more when encouraged by the license

(aka “in vitro”) Package your application with data, libraries, all that in a VM. cde, Howe, escienceVM

Quoth Howe

"Under this model, it is no easier than in the status quo to
extract and repurpose some part of the pipeline. But this is not a job for the
reproducible research community to solve; effective reuse is a long-standing issue
in software engineering. The problem in this domain, in fact, is exacerbated by
the fact that, by definition, research programmers are often operating at the
frontier of applied computing, and should be free to mix and match tools from
various contexts as needed. We should not expect to be able to 'standardize
science.'"

• less work. No need to obsess that much in portable software.
• remix-unfriendly: less useful idyll
• how much do you package? What hypervisors out there 5, 10 years from now?
• can you package the hardware? How do you package an Nvidia GeForce 8800 GT (CUDA)?

Licenses don't matter that much here (besides allowing your prospective users to use your VMs, that is).

Howe classifies vendor lock-in and longevity as an imagined challenge. I tend to disagree.

• http://blends.debian.net/
• http://blends.debian.net/science/

• http://escience.washington.edu/blog/reproducible-research-and-cloud-computing

• http://ivory.idyll.org/blog/vms-considered-harmful.html

• http://nixos.org/

• http://escience.washington.edu/get-help-now/create-virtual-machine-software-bundling-or-reproducible-research

• http://www.pgbovine.net/cde.html

• On JSTOR
• Building JSON-glib vs building a particle collider
• Open Source Sustainability
• Donald Knuth on Literate Programming, the Menace of Code Reuse and Other Things
• Gardler: Open Source and Academia, Slashdot discussion (The blog article is a bit weak, but the Slashdot discussion is quite instructive, with many posts by involved people)

• http://www.methodsandtools.com/archive/archive.php?id=3
• http://en.wikipedia.org/wiki/Configuration_management
• http://www.faqs.org/docs/Linux-HOWTO/Software-Release-Practice-HOWTO.html

Back to workshop 2013-02-06