Want to help us test? Add your info here. #1
Comments
|
Scott Edmunds @gigascience |
|
Amye Kenall @OpenDataBMC |
|
Varsha Khodiyar @F1000Research |
|
Phil Bulsink @pbulsink |
|
Rob Davidson @bobbledavidson |
|
Hilmar Lapp @hlapp |
|
Ariel Rokem @arokem In particular, https://github.com/vistalab/osmosis |
|
Karthik @karthik |
|
Aron Ahmadia @ahmadia (And I've got some wild ideas about integration with HashDist and IPython Notebook). |
|
I'd be interested. @zeckalpha |
|
Morteza Milani @milani |
|
Raniere Silva @r-gaia-cs |
|
Fabian Schreiber @fabsta |
|
Rémi Emonet @twitwi |
|
Ed Borasky - @znmeb on Twitter |
|
Count me in @drchriscole |
|
Simon Li @manics |
|
Ethan White @ethanwhite. We have bootstrapped version of the core idea for some of our code. I'd be happy to move over to the new system. See: |
|
Thomas Arildsen @ThomasA. |
|
Robert M Flight @rmflight |
|
Haiyan Meng @hmeng-19 |
|
Cristóvão D. Sousa @cdsousa |
|
Eduardo Pareja-Tobes @eparejatobes |
|
Peter Ansell @ansell |
|
Andrew Barr @wabarr |
|
Thomas Henderson tom@mathpunk.net |
|
B. Arman Aksoy @armish |
|
Juande Santander @juandesant |
|
Stuart Mumford @Cadair |
|
Susheel Varma @susheel |
|
Paolo @cbcrg |
|
Chris Hartgerink @chartgerink |
|
Daisie Huang @daisieh |
|
Valentin Churavy @Wallnuss |
|
Andrew Straw @astraw |
|
I'd love to help! -sung |
|
+1 |
|
Matt Shirley @mdshw5 |
|
Gerard Gorman @ggorman |
|
I'd love to help. At the COIN-OR Foundation (www.coin-or.org), we've been talking about how we can make code into a peer-reviewed, citable publication for years, but this is the most positive step I've seen to that end. We would love to be a partner in making this happen. |
|
So much that is being overlooked is not simply " get me the code + data " ... but the environment on top of that. How many researchers here do we have with native packages running on their machines? How deep do the dependencies go? One HUGE advantage of cloud computing here is that we've got CLEAN boxes to ensure ALL dependencies are installed. "Just the data" and "just the code", is only half the headache of getting the desired outputs. It seems like we're overlooking the substantial work that goes into provisioning the environments. |
|
I would expect anyone experienced in porting non-trivial codes to agree with you. I also think there is a lot of milage in this idea but it has not quite been universally received. Here is an interesting short commentary on the subject: |
|
@ggorman VMs are substantial in size and as stated in the article: black boxes. We don't want that. We want install processes to be determined in code and executed on instancing of the box. |
|
There is often a gap between what we want in an ideal world, and the pragmatic decisions we have to make progress. I agree with the position you are taking (although I would be interested to understand how this would be done since there are many package managers and no universal agreement on the right way of doing this) - but I also believe we should support other circumstances with a history that would require massive (unavailable) resources to re-engineer. Grabbing a piece of software and porting it to a system is not always easy. In fact it can be a massive challenge in itself. I can list several large packages that are doing really good science that have many 10's of dependencies on other substantial libraries. As systems and compilers are updated any part of this can break in lots of interesting (i.e. infuriating) ways. I regularly run into problems porting code where something that used to be accepted by a compiler is no longer acceptable. Again, this is no big deal if you are working on one small project - but if you talking about something substantial with possibly millions of lines of code in many different languages from across the globe it becomes a herculean task if not impossible due to finite human resources. |
|
I would be happy to help test. |
|
@carlcrott and @ggorman #2 seems a good place to bring up virtualization. |
I think these sound like smart places to start. Also is everyone here working for free? If they're big packages there should be some financial support sourcing specifically from the primary owners of the code. I would start with chef as their primary offering is an attempt to abstract away OS differences. As stated above its a hard task, however they've got $$$ ... So its a smart bet to take that they're not going to go evaporating. |
|
Great initiative! @mickeypash |
|
I'd also like to test. @mbjones We're assembling a similar system for the KNB and an open API for DataONE for sharing these objects, and so would love to discuss interoperability with you. |
|
James Manton @ajdm |
|
J. Richard Snape Twitter:@snapey1979 |
|
I am currently running a course on Coursera called "Massive Teaching: New skills required". This course is a meta-MOOC, talking about the skills associated to MOOCs, and engaging instructors to think about the consequences of teaching on open/commercial MOOC platforms. In the upcoming week, I want to engage my 7000 students in the following topics: open science, open data, open source, open software, crowdsourcing, crowdstorming of datasets, and "code as research object". I guess I have finally found the right place on the web to tie all those ideas together, if anyone is interested. You could simply watch the videos, but the forums are much more fun, and you will probably want to participate. |
|
David Ketcheson @ketch |
|
Rad @radaniba |
|
Richard Littauer. |
|
Vinod Pahuja |
|
Chris Bogart |
|
Jose Barrios @BarriosJose (Tweeter) |
and others
We're looking for publishers and researchers to help us test new ways of giving credit to code. Want to help? Add your info here.
The text was updated successfully, but these errors were encountered: