Re: Docker and singularity containers

[swedebugia <swedebugia@riseup.net>]

[-- Attachment #1.1: Type: text/html, Size: 4717 bytes --]

[-- Attachment #1.2: Type: text/plain, Size: 3955 bytes --]

zimoun <zimon.toutoune@gmail.com> skrev: (6 januari 2019 13:09:33 CET)
>Dear Mike,
>
>Thank you to raise this concern here.
>I was aware of this thread and I do not fully agree with the arguments.
>:-)
>I am doing 3 comments.
>
>
>First, from my point of view, we need to distinguish between the
>"puller" and the "pusher".
>And correct me if I am wrong, but one does not need an account to pull
>a Docker from DockerHub. Therefore, I do not see the issue from the
>puller side.
>Because if we apply the argument, do the GPL licensed softwares on
>GitHub respect the freedom of the user?
>
>The issue is about the "pusher" i.e. the GNU Guix project. And yes,
>the GNU Guix has to accept to run non-free softwares to be able to
>push on DockerHub. Is it acceptable?
>
>
>Hence, my second comment is about the _how_ to distribute. Currently,
>there is no free alternative to publish Docker image; even if docker
>provides a mechanism to pull from elsewhere than DockerHub.
>It is an issue about money and man power. It will be a pity to not
>spread enough free software political ideas because the movement lacks
>resources. And it is not about be hypocritical, I guess.
>
>If I may, I quote the paper from the Guix maintainers---correct me if
>I am wrong.
>https://arxiv.org/abs/1506.02822 last paragraph from section 5
><<
>Proprietary software.
>GNU Guix does not provide proprietary software packages.
>Unfortunately, proprietary software is still relatively common in HPC,
>be it linear algebra libraries or GPU support. Yet, we see it as a
>strength more than a limitation. Often, these “black boxes” inherently
>limit reproducibility—how is one going to reproduce a software
>environment without permission to run the software in the first place?
>What if the software depends on the ability to “call home” to function
>at all? More importantly, we view reproducible software environments
>and reproducible science as a tool towards improved and shared
>knowledge; developers who deny the freedom to study and modify their
>code work against this goal.
>>>>
>
>Here, my personal opinion. Today, people think that the Science crisis
>about reproducibility will be tackled by Docker and containers. On one
>hand, I am here because I think it is wrong and it is not the path to
>go. On the other hand, I need to pragmatic: people in labs have built
>infrastructures using Docker or equivalent; they wont be convinced
>easily to switch and so I think I want to ease the switch in playing
>directly in their ground.
>
>
>Last, I do not understand how to apply the argument against pushing to
>DockerHub to the Windows port of Emacs.
>Somehow, GNU has to run non-free softwares to provide this port. At
>least to launch some tests.
>
>My personal opinion is that it is good. Because this spreads the
>message about freedom, this helps people to be aware of the movement,
>this should be a first step in liberating users.
>
>
>Thank you if you have comments and/or if you have arguments that
>explain me where it is wrong.
>
>
>All the best,
>simon

+1 
I never used docker. 

It would probably have helped me when I set up my now broken accounting software (odoo 9) before I knew about dolibarr and before guix had containers. (It broke some time ago when I upgraded arch :/ Shared libraries are a stability risk and pain in the long run)

According to the Swedish state I have to make sure my accounting software is working 7 years after the end of each year.
This is to my surprise really hard with software like odoo. I would have upgraded long ago would it have been straightforward by the developers (odooization as i call it is a problem, they make money on making odoo a fast changing maze that has really poor documentation, cryptic errors and no free upgrade scripts necessitating a whole industry of paid supporters.)
-- 
Sent from my p≡p for Android.

[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 3825 bytes --]