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

[Ryan Prior]

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