unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Mike Gerwitz <mtg@gnu.org>
Cc: guix-devel <guix-devel@gnu.org>,
	"Ludovic Courtès" <ludovic.courtes@inria.fr>
Subject: Re: Docker and singularity containers
Date: Sun, 6 Jan 2019 13:09:33 +0100	[thread overview]
Message-ID: <CAJ3okZ0cqb1qWDDXNzFH64ANZe01dXjGg0-9TSYOby79fM5Gaw@mail.gmail.com> (raw)
In-Reply-To: <877efixyz3.fsf@gnu.org>

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

  reply	other threads:[~2019-01-06 12:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12 15:16 Docker and singularity containers Pjotr Prins
2018-09-12 17:35 ` Ludovic Courtès
2018-09-12 17:43   ` Ricardo Wurmus
2018-09-12 18:30     ` Pjotr Prins
2018-09-12 20:59       ` Ricardo Wurmus
2018-09-13  6:10         ` Pjotr Prins
2018-09-13  7:21           ` Ricardo Wurmus
2019-01-04 18:57             ` zimoun
2019-01-05 16:14               ` Ricardo Wurmus
2019-01-06  3:10                 ` Mike Gerwitz
2019-01-06 12:09                   ` zimoun [this message]
2019-01-08  9:07                     ` swedebugia
2019-01-08  9:10                     ` swedebugia
2019-01-15 12:31                 ` zimoun
2018-09-13  6:53         ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJ3okZ0cqb1qWDDXNzFH64ANZe01dXjGg0-9TSYOby79fM5Gaw@mail.gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=ludovic.courtes@inria.fr \
    --cc=mtg@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).