Skip to content

Fix i -> I #114

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
vsoch merged 1 commit into from
Sep 27, 2017
Merged

Fix i -> I #114

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion pages/docs/user-docs/docs-apps.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -113,7 +113,7 @@ To motivate the first need, let’s imagine a scenario where a researcher is dev
The next need is driven by a larger goal of encouraging reproducible practices. At first glance, containers are a leap in the right direction. Given that all dependencies are packaged nicely, a container is very reproducible. Given this level of representation, a container gives the user absolutely everything - a complete operating system with data, libraries, and software. But this also means that we are producing heavy containers to serve a small amount of software. In terms of reproducibility, we have lost modularity because best practices implement a module on the level of an operating system, and not on the level of the software installed. There are several problems with this practice:

- Containers are not consistent to allow for comparison. Two containers with the same software installed in different locations do not obviously do the same thing, despite this being a possibility.
- Containers are not transparent. If i discover a container and do not have any prior knowledge or metadata, a known function may be completely concealed.
- Containers are not transparent. If I discover a container and do not have any prior knowledge or metadata, a known function may be completely concealed.
- Container contents are not easily parseable, or programmatically understandable. I should be able to run a function over a container, and know exactly the functions available to me, ask for help for a function, or how and where to interact with inputs and outputs.
- Container internal infrastructure is not modular. We would be weary to export an entire container into another because of overlapping content.

Expand Down