This is heading in the right direction - in my analysis, many things we do, including Free Software, are all forms of creative subversion of Capitalism. We need note creativity, not less đ
> On Mar 20, 2022, at 03:19, Ryan Prior <rpr...@protonmail.com> wrote: > > ï»żZimoun wrote: >> Today, Guix provides a script that allows to install on any foreign Linux >> distribution. [...] Guix provides a ânightlyâ VM. And, IIRC, Guix is also >> available via upstream Gnome boxes. Somehow, it is already âGuix for >> Desktopâ, 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 > specifically 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 first > install a VM manager dependency like QEMU or VirtualBox. The installer for > Docker creates and manages a VM automatically, which is treated as de-facto > immutable and never exposed to the user at all. It is locked down, > automatically updated, and doesn't provide the user any way to install new > software 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 connecting > 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 dev > machine but are deploying to GNU/Linux boxen. By standardizing on Docker for > Desktop, organizations are able to provide a consistent GNU toolchain to 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 Flatpak > &c alternative, to just run some software. And that particular use case is > 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 for > 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, >> which 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 say > 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 with 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 >> Guix? I agree that things are lacking for more adoption but I miss what you >> would have in mind with âGuix for Desktopâ. > > Some organizations using Docker on the server would be even better served by > 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 them > using Guix. > > But for a variety of reasons organizations commonly have a heterogeneous > environment, 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 > workflows, 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 > reconfigure," 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 from 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 > shell 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, carries > the performance penalty of a VM, adds complexity, &c. But for the specific > 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 > prod.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 > organizations are great. > > Let me stop there, thanks for reading a long email! Or if you got bored and > gave up, sorry! =D > > Ryan >
