From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id iCYKJKgeNmKIUwEAgWs5BA (envelope-from ) for ; Sat, 19 Mar 2022 19:19:20 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id SDh8IageNmIJwwAA9RJhRA (envelope-from ) for ; Sat, 19 Mar 2022 19:19:20 +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 297802E6FB for ; Sat, 19 Mar 2022 19:19:20 +0100 (CET) Received: from localhost ([::1]:56298 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nVdfb-0002cL-9W for larch@yhetil.org; Sat, 19 Mar 2022 14:19:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38592) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nVdeV-0002cC-JQ for guix-devel@gnu.org; Sat, 19 Mar 2022 14:18:11 -0400 Received: from mail-4322.protonmail.ch ([185.70.43.22]:19883) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nVdeT-0002UP-3d for guix-devel@gnu.org; Sat, 19 Mar 2022 14:18:11 -0400 Date: Sat, 19 Mar 2022 18:18:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1647713886; bh=v4tm7vWYwedFiz4rRLlSQK+yKi5LxIxShyGspZic5a4=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=MtTGlUfQ7zoANSe2k3J+D6efUg3A3CWQ8S0qYN9yiz+JVhbz2wsWydtRYp0a+qIij JygLsvvKwuOmYokIJQ0tAVGN4BhZn1hcUIAZ0PiYEB5lqhlYYE3WgR9XxHXu3AF9XP jnPcRJDlEf5doExtgvbY8IhlCbPQICZSr/XmBi4SIvYFL3/yZ7xmT8ZdnQIUZIrpON 9GqAvuW8UxnU+rTEs6IarDEkJUZFiyQ54PDXydGaIzk7Pq4ib9K1YT7EudZsVyDdx8 Ati8drkF7BbEW+hSNssvGgIhU5wwwwW02RKoqiGoMHXe9H60D3o6WYZsjkokcRx7h7 KlDYVOYzOWhgA== To: zimoun , Liliana Marie Prikler From: Ryan Prior Cc: Guix Devel Subject: Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works) Message-ID: In-Reply-To: <86cziidqnw.fsf@gmail.com> References: <86cziidqnw.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.43.22; envelope-from=rprior@protonmail.com; helo=mail-4322.protonmail.ch 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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: , Reply-To: Ryan Prior 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=1647713960; h=from:from:sender:sender:reply-to: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:dkim-signature; bh=v4tm7vWYwedFiz4rRLlSQK+yKi5LxIxShyGspZic5a4=; b=cgRZMvgTMlSiFBDRYDrka67xnkdhKHaOgUBIuEUVvOgPmblVhbvabXV3Lda3Y5Ai2YpvFq /bEeJI0XduyFY5P2YRT8v2S5Z1iHVK80o+bgfGfJmDfoC+q0Rc2sxauOjrb0aWYt4GEQdN y53fY01y3EbSKOYcBM2r+ED+uI8uu7ZIFrrTMSz2ww0sTWTACJ0juboOVdds/csMJeEMC2 B7MT2bxAD8g79f75VurShuNo9mhZJSnwoNOXx8+vOnCKISDzvFN5cG2/gARG0nqdNDKCiA evOX4QMReehQ0Uv42XNDeYvs7BP7uO6E/kzoOmcPaAYTRmdXEFch66rrKihRpQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1647713960; a=rsa-sha256; cv=none; b=hZPxrJquKXZAX60Xq1K3QalImXVDFGcUgMlSov83uQlfb3/VGwsXdVOTcNFqIPlDWLAD/a p4uXI6XasX2Ao0fvj/EO5R+SwBH1OyBd9wr5yjIVUp6zKciYAfMk5wvWGDPjbatB6GJ7R+ xNnYmKR9FgEPByeNSckghOdY1N1P6YGCdSDSO42iuzyKmYgFo4vVovAmRhA5jpx2yOdjH7 1wSzF/RD18spX+wLBRnsuZb5Y4xvY6B3AHQxGThOnZUgRaO8IQ0NLaL8f6yuygAD0W32xk sJpEe94lTabIurf0ncgkZou5VGmOZKA1hZt3jLuDrZtxg1bCFLIgmi9/f6C7Vw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=MtTGlUfQ; dmarc=pass (policy=quarantine) header.from=protonmail.com; 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: -4.14 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=MtTGlUfQ; dmarc=pass (policy=quarantine) header.from=protonmail.com; 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: 297802E6FB X-Spam-Score: -4.14 X-Migadu-Scanner: scn1.migadu.com X-TUID: Bq9KpCtDZA3K Zimoun 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, IIR= C, Guix is also available via upstream Gnome boxes. Somehow, it is already = =E2=80=9CGuix for Desktop=E2=80=9D, no? ;-) 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 spe= cifically as an interface and a tool to build, test, and deploy software. (= This is what I meant by "end-user dev tool" in my email title and I regret = that I didn't explain up front in more detail what I meant.) This brings a = whole different set of assumptions from the common case where the end-user = just wants to run some software and the building & testing are incidental. When I install Docker for Desktop on macOS or Windows, I do not have to fir= st 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-fa= cto immutable and never exposed to the user at all. It is locked down, auto= matically updated, and doesn't provide the user any way to install new soft= ware or make changes to it. It's not like a distro: it provides only what's= necessary to run containers, with no desktop, no coreutils, no SSH, no VNC= , practically no userland at all. 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= doesn't have to configure or manage any of this. And thus with each Docker= command. 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. 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 = for Desktop, organizations are able to provide a consistent GNU toolchain t= o all their developers and operators, smoothing out the differences between= platforms and decreasing complexity. I acknowledge that people also sometimes use Docker for Desktop as a Flatpa= k &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 = deploy software, every developer who uses a non-free OS likely has Docker f= or Desktop installed. This amounts to hundreds of thousands of daily users,= at least. >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. It is uncommon to run a full distro using Docker for Desktop. I wouldn't sa= y unheard of, but overwhelmingly the most common use case is to do exactly = what you describe, building and running small containers with a service in = them. 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 wi= th the Docker daemon. You just install Docker for Desktop and interact with= Docker the same as you would with GNU/Linux. 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 = would have in mind with =E2=80=9CGuix for Desktop=E2=80=9D. 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= those who decide to keep using OCI containers can benefit from building th= em using Guix. But for a variety of reasons organizations commonly have a heterogeneous en= vironment, 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= offer a "Guix for Desktop" installer that enables uniform developer workfl= ows, such that "guix build -f my-app.scm" works the same on any client, and= so on for each Guix command. This would necessarily exclude some commands, like and "guix system reconfi= gure," which are expected to mutate the user's base system. Installed this = way, every interaction with Guix would be in a Guix container, with files f= rom the host system mounted into it. If I ran "guix install coreutils" then= the installed "ls" would be a shell script that runs ls inside a Guix shel= l in the VM, with the current directory mounted into it. 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, carr= ies the performance penalty of a VM, adds complexity, &c. But for the speci= fic case where the end-user is a software engineer on a non-free OS who is = building, testing, and deploying software using Guix, it could be excellent= . You'd check out your repo, "guix build my-app.scm," then "guix deploy pro= d.scm" and off you go. These things happen principally in the domain where = we aren't interacting with the host system much anyway, so the limitations = matter little, while the benefits to people working in heterogeneous tech o= rganizations are great. Let me stop there, thanks for reading a long email! Or if you got bored and= gave up, sorry! =3DD Ryan