Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)

[Ryan Prior <rprior@protonmail.com>]

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