isn't this the good thing about academia? aren't you kids getting paid the big bucks to write and maintain the software libraries, while we work on novel problems for pennies?
isn't this the good thing about academia? aren't you kids getting paid the big bucks to write and maintain the software libraries, while we work on novel problems for pennies?
A few people are fighting this (Titus Brown, etc) but it's mostly swimming against the tide of bad incentives.
Often times, and especially from what I've seen in the computer vision papers, the authors merely state what algorithm they used, and how they combined it with their novel method. And that algorithm is in another paper, by the way, probably by the same author. Definitely not the implementation you're working with, too, if you have it.
It's almost as if they need a combined repository. And each paper that presents a novel algorithm, or implementation of an existing one, is a "changeset" or "branch". And the citations to algorithm's used in a paper would be changeset hashes, or branch names. Hey, it's the first thing that popped into mind for me to solve this horrendous problem.
Unfortunately my experience is that too many academic groups believe that their source code is the route to untold riches.
if the experimental data is proprietary, or you want to keep it separate, you can set a mount point for it in the lxc.
http://pgbovine.net/publications/CDE-create-portable-Linux-p...
edit: well no surprise there i guess! http://www.nextflow.io/blog/2014/nextflow-meets-docker.html
Replicate the experiments, or just repeat the results?
I don't deal with much scientific code myself, but at one point I dealt with a proof-of-concept cryptographic library from a reasonably well-respected researcher. The code behaved correctly from the outside, but when I dug into it, deviated wildly from the published specification.
It only lasted a few years, but I find the idea of exiting long lasting research founded on bad code a to be very real possibility.
i would argue that the two are the same in this case.
the lxcs provide all the source code i write [plus of course the compiled version], all third-party libraries, and all scripts used to run and evaluate the experiments, and the data as well, where that is permitted.
it's still not perfect, but for my area, i honestly think it is the best, and most accountable way to do things that i have seen.
the point of the docker/lxc aspect is to provide a simple working environment to facilitate replication and validation.
so in comparison to the status quo, which is basically 'write a paper, include some high level equations, and results', i think this is a step forward in a better direction.
Even for decent code, docker is being over-sold for this sort of thing. Serious large-scale calculations, in particular, simply aren't hardware-independent in practice. Consider a 1024-core PSM MPI job with Haswell-specific code or requiring some GGPU, or a 128-core, 2TB SMP one; you can't run them anywhere. Even if you can package and run in docker at another site, if you don't get the "right" results, what do you do about it if you don't have source?
i don't think it is an oversell, in the sense that it is still unusual to include source code and experimental setups [at least in my field]. a replicable environment with included source code is a large step forward.
sad as that might be.
have you read Cryptnomicon look at how Randy's first job at a University is described.