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

[Yasuaki Kudo]

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 <rprior@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
>