From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Brian Cully via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] new package: tramp-docker Date: Mon, 10 Oct 2022 09:55:37 -0400 Message-ID: <871qrfkckm.fsf@ditto.jhoto.spork.org> References: <5674f36a-c276-fd77-b4d2-1525c75a1602@spork.org> <871qrkkrvv.fsf@posteo.net> Reply-To: Brian Cully Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15869"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: rms@gnu.org, Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 10 15:57:24 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ohtHW-0003pM-WE for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Oct 2022 15:57:23 +0200 Original-Received: from localhost ([::1]:59232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ohtHV-00011v-Uq for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Oct 2022 09:57:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34332) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohtGO-0008Gx-7z for emacs-devel@gnu.org; Mon, 10 Oct 2022 09:56:12 -0400 Original-Received: from coleridge.kublai.com ([166.84.7.167]:54763 helo=mail.spork.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohtGL-0000Dd-Sd; Mon, 10 Oct 2022 09:56:11 -0400 Original-Received: from ditto (ool-18b8e9e7.dyn.optonline.net [24.184.233.231]) by mail.spork.org (Postfix) with ESMTPSA id 43A4C8E13; Mon, 10 Oct 2022 09:55:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=spork.org; s=dkim; t=1665410146; bh=s6kcvBUux5CJcG4Yga1KKNkhJyG3gDZx6E/j6sKkFrs=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=onAse6g4QMtftmb8XsSg94EIS3MNZHYOm8zal3HUz5P3+/pCjhIp1cg5X77QhqaDX pVf9rbNw7lcHtT4LRkpbqNi2LeJSX5ViXHEL96XVE95/AVV9Ix7/EcyAoM+Dcd6PgN kUIiilS5dUHzY71pFJiKqGcpBVX1rbHSo7FjAm3g= In-Reply-To: Received-SPF: pass client-ip=166.84.7.167; envelope-from=bjc@spork.org; helo=mail.spork.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:297365 Archived-At: Richard Stallman writes: > > To my knowledge there is the danger of either having a build-time or a > > run-time dependency on a non-free container, > > That's what was reported to me. > > Does Docker provide an easy way to verify that you have avoided such > dependencies? A way to make sure to avoid including them? No it does not, but I do not regard Docker or its ilk as special here. They provide a framework for running an operating system. *Inspecting* that operating system is just as out-of-scope for those projects as it would be for Qemu. > Is that the _only_ way to develop a container? Is it possible, > practically speaking, to build a container without using that site at all? There are a host of ways of building containers, and there are open specifications for how to do so (see the Open Container Initiative), which are all APL-2.0 licensed, to my knowledge. Additionally, GNU's own Guix project provides a way to create Docker containers for Guix, from the ground up. > Alas, that does not by itself ensure that, supposing you build a containe= r, > you won't consider including nonfree programs. > > Is there an easy way you can ensure that _all_ the programs you put > into a new container are free? Is there an easy way to verify that > the contents of a container are free? Is there an easy way to do that on any given operating system? If so, then yes, there is a way, and it is the same tool. If there is no such tool, that's not a Docker problem, and such a tool should be created, at which point it will be applicable to containers or other virtualization technologies. Because the entire aim of these technologies is to present an interface that looks very close to a physical machine (within some limitations). > > > 3. Distributing free programs in containers tends to be bad for > > > the community's control over the program. Because people > > > don't build the program on the GNU/Linux distros they use, > > > and don't package it for those distros. > > > > > > This too we should use the opportunity to warn people about. > > > I think this could be added to the commentary section. > > Maybe so, but when you say "the commentary section", could you > be more precise? The commentary section of what documentation? Personally, I don't think adding these notes to the =E2=80=9CCommentary=E2= =80=9D section is appropriate, any more than it would be appropriate to add it to the SSH support. I see no difference, in the abstract, end-user sense, between accessing a remote server via SSH or Docker. They accomplish the same goal, with the same drawbacks, in broadly similar ways. -bjc