From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id uEvEIwBgNmIAKQEAgWs5BA (envelope-from ) for ; Sat, 19 Mar 2022 23:58:08 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id EPOVIABgNmIdvgAAauVa8A (envelope-from ) for ; Sat, 19 Mar 2022 23:58:08 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 024BC11C7B for ; Sat, 19 Mar 2022 23:58:08 +0100 (CET) Received: from localhost ([::1]:47680 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nVi1P-0000m9-4k for larch@yhetil.org; Sat, 19 Mar 2022 18:58:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59992) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nVi0z-0000m0-7k for guix-devel@gnu.org; Sat, 19 Mar 2022 18:57:41 -0400 Received: from mail1.g12.pair.com ([66.39.4.99]:12991) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nVi0x-0003X3-Dp for guix-devel@gnu.org; Sat, 19 Mar 2022 18:57:40 -0400 Received: from mail1.g12.pair.com (localhost [127.0.0.1]) by mail1.g12.pair.com (Postfix) with ESMTP id 2A5DF71E5A3; Sat, 19 Mar 2022 18:57:36 -0400 (EDT) Received: from smtpclient.apple (w135107.ppp.asahi-net.or.jp [121.1.135.107]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail1.g12.pair.com (Postfix) with ESMTPSA id F3830745736; Sat, 19 Mar 2022 18:57:35 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Yasuaki Kudo Mime-Version: 1.0 (1.0) Subject: Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works) Date: Sun, 20 Mar 2022 07:57:33 +0900 Message-Id: References: In-Reply-To: To: Ryan Prior X-Mailer: iPhone Mail (19D52) Received-SPF: none client-ip=66.39.4.99; envelope-from=yasu@yasuaki.com; helo=mail1.g12.pair.com X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Guix Devel , Liliana Marie Prikler , zimoun Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1647730688; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=+Rdacj3XDlEIdS39dI+/KbYIJ45OCPfN5wCHJk9FINs=; b=Mq2mZEf0xQX0CYldfdc6yhSCEQ8+9jhUhBG/2Ztp1wVZGIWLvzX2CxXRHP4yINcMF+49sw QUnPGEtIOremGd2vJ2/rufmRA7A6rQBWNCA2M6sXv3+x3P4oOB6rz/ApGFuG2keKB5Ik6z BhdiBCyuP6cncu+aA1MRp2TK8HayI+VT8n3gqw7ZaP/qm5s06FBuv9utlPrMbwIG+XM3k+ k9NKaz0c/cWB48o1+29nHe2syU+2H6GTsyPb2cIjH+aNrcSyiWOqFpmfoS/CvRdB2Btfl1 sfimlx8zrhaIK7HKTQvSmEkPcGzr6SFIdln5es/YI5Pu5wyhIxvrk+RRNaqxdA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1647730688; a=rsa-sha256; cv=none; b=atDcgMvnf8ik2hkl6ParmXmxyB1+rARYbM60WWPU39fQLoMFZCjIl6J7MFfRYYrccI9iXC IlIEVNuzAZxfaIn94+RA4p+pxwM87xNSbzM2Rtv9+qAxXZxHUTKhbP8a2ys+/l5rERDHki 560r25PdXWjcWXXkU6k4LWbENdy6BMurN8DbZRzQxZ5J8EhYigLmYEAOwbxFXOMty3NGJ6 4Qhnc+lpTZZF4U8tyCJ/0UFVhIH1/yunsumqo9cuM0m/xjcE2odjnp2UmY4zt4FOa1wVbd /ui1Nh5Sk7sc34UVJHOG5bzTy7p9S+MeXaj47BiicJB0iRlwAr1rdY0zUKllLw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -1.03 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 024BC11C7B X-Spam-Score: -1.03 X-Migadu-Scanner: scn1.migadu.com X-TUID: Flg9Sh0tb/1k This is heading in the right direction - in my analysis, many things we do, i= ncluding Free Software, are all forms of creative subversion of Capitalism. = We need note creativity, not less =F0=9F=98=84 > On Mar 20, 2022, at 03:19, Ryan Prior wrote: >=20 > =EF=BB=BFZimoun wrote: >> Today, Guix provides a script that allows to install on any foreign Linux= distribution. [...] Guix provides a =E2=80=9Cnightly=E2=80=9C VM. And, IIRC= , Guix is also available via upstream Gnome boxes. Somehow, it is already =E2= =80=9CGuix for Desktop=E2=80=9D, no? ;-) >=20 > An important bit of context here is that I'm talking about the case where a= software engineer is the end-user of Docker (or of Guix,) utilizing it spec= ifically as an interface and a tool to build, test, and deploy software. (Th= is is what I meant by "end-user dev tool" in my email title and I regret tha= t I didn't explain up front in more detail what I meant.) This brings a whol= e different set of assumptions from the common case where the end-user just w= ants to run some software and the building & testing are incidental. >=20 > When I install Docker for Desktop on macOS or Windows, I do not have to fi= rst install a VM manager dependency like QEMU or VirtualBox. The installer f= or Docker creates and manages a VM automatically, which is treated as de-fac= to immutable and never exposed to the user at all. It is locked down, automa= tically updated, and doesn't provide the user any way to install new softwar= e or make changes to it. It's not like a distro: it provides only what's nec= essary to run containers, with no desktop, no coreutils, no SSH, no VNC, pra= ctically no userland at all. >=20 > The only point of interaction with the VM is through the Docker daemon. On= Windows or Mac when you run `docker build` the client software is connectin= g to the daemon in the VM, sending it the build context, etc - but the user d= oesn't have to configure or manage any of this. And thus with each Docker co= mmand. >=20 > Liliana Prikler wrote: >> But who are those users of Docker for Desktop? For me, that seems to be a= niche even smaller than flatpak et al. >=20 > The target demographic is developers who, whether out of preference or for= corporate compliance or some other reason, use macOS or Windows on their de= v machine but are deploying to GNU/Linux boxen. By standardizing on Docker f= or Desktop, organizations are able to provide a consistent GNU toolchain to a= ll their developers and operators, smoothing out the differences between pla= tforms and decreasing complexity. >=20 > I acknowledge that people also sometimes use Docker for Desktop as a Flatp= ak &c alternative, to just run some software. And that particular use case i= s indeed niche. But at companies that use Docker on the server to test and d= eploy software, every developer who uses a non-free OS likely has Docker for= Desktop installed. This amounts to hundreds of thousands of daily users, at= least. >=20 >> Running a full-blown distro inside docker defeats the purpose of docker, w= hich is to run only the parts necessary to keep your microservice alive. >=20 > It is uncommon to run a full distro using Docker for Desktop. I wouldn't s= ay unheard of, but overwhelmingly the most common use case is to do exactly w= hat you describe, building and running small containers with a service in th= em. The value proposition of Docker for Desktop is that you don't have to do= the work of managing a VM or even SSH into a VM in order to interact with t= he Docker daemon. You just install Docker for Desktop and interact with Dock= er the same as you would with GNU/Linux. >=20 > Zimoun wrote: >> What do you have in mind for smoothing the workflow of end-user running G= uix? I agree that things are lacking for more adoption but I miss what you w= ould have in mind with =E2=80=9CGuix for Desktop=E2=80=9D. >=20 > Some organizations using Docker on the server would be even better served b= y Guix, and even moreso as our project matures. As Liliana points out, even t= hose who decide to keep using OCI containers can benefit from building them u= sing Guix. >=20 > But for a variety of reasons organizations commonly have a heterogeneous e= nvironment, with GNU/Linux on the server and a mix of free and non-free OSes= on the client. They would face a much lower barrier to adopt if we were to o= ffer a "Guix for Desktop" installer that enables uniform developer workflows= , such that "guix build -f my-app.scm" works the same on any client, and so o= n for each Guix command. >=20 > This would necessarily exclude some commands, like and "guix system reconf= igure," which are expected to mutate the user's base system. Installed this w= ay, every interaction with Guix would be in a Guix container, with files fro= m the host system mounted into it. If I ran "guix install coreutils" then th= e installed "ls" would be a shell script that runs ls inside a Guix shell in= the VM, with the current directory mounted into it. >=20 > This would not be an ideal system for installing and managing software on a= non-free OS and I wouldn't recommend using it for such: it's limited, carri= es the performance penalty of a VM, adds complexity, &c. But for the specifi= c case where the end-user is a software engineer on a non-free OS who is bui= lding, testing, and deploying software using Guix, it could be excellent. Yo= u'd check out your repo, "guix build my-app.scm," then "guix deploy prod.scm= " and off you go. These things happen principally in the domain where we are= n't interacting with the host system much anyway, so the limitations matter l= ittle, while the benefits to people working in heterogeneous tech organizati= ons are great. >=20 > Let me stop there, thanks for reading a long email! Or if you got bored an= d gave up, sorry! =3DD >=20 > Ryan >=20