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

[Liliana Marie Prikler]

Hi,

Am Samstag, dem 19.03.2022 um 00:20 +0000 schrieb Ryan Prior:
> One side-thread in "Building a software toolchain that works" notes
> that Guix faces challenges for adoption because it's not readily
> available to users of proprietary operating systems like macOS and
> Windows.
That's true to an extent for most Linux-first applications.

> I've witnessed over the past decade that GNU/Linux development on
> other platforms has become widespread, in large part due to the
> availability of the Docker for Desktop application which packages a
> lightweight, automagically managed GNU/Linux virtual machine running
> the Docker daemon with Docker client software built for the target
> platform.
> 
> A user of Docker for Desktop on a proprietary OS can run "docker"
> commands which transparently execute commands inside a GNU/Linux
> container, making building and testing software quite convenient and
> reproducible without needing to set up cross-compile toolchains or
> spend time managing VM software.
> 
> It makes absolute sense to me that Guix is not interested in building
> a native distribution for the Windows or macOS toolchains. One of
> Guix System's unique strengths is its adherence to the GNU FSDG and I
> don't think that's incompatible with making the Guix tools more
> generally available to end-user devs hacking on software using a
> proprietary OS.
But who are those users of Docker for Desktop?  For me, that seems to
be a niche even smaller than flatpak et al.  Even if they exist, Guix
already caters to them by providing `guix pack', which among others can
distribute docker containers.  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.

> Technically, I think we could use a similar approach to the Docker
> for Desktop system: a "Guix for Desktop" installs software to create
> and manage a minimal Guix System virtual machine which automatically
> updates and reconfigures itself, requiring no manual administration
> by the end-user. And it would install a Guix client that connects to
> the Guix daemon running in the VM using a shared socket, enabling
> users to incorporate Guix transparently into their workflows.
> 
> I think this would be a compromise for certain, the same way it is
> for Emacs and other GNU flagship projects that run on non-free
> systems. On the one hand, it serves to make those systems more
> valuable, which undermines our cause. But on the other hand it
> provides a major on-ramp to free software and superior build tooling,
> positively impacting the practical freedoms available to the end-
> users who adopt Guix.
Automatic updates suck on proprietary systems and Guix could not do
anything to address that.  Even in free software, there are arguments
to avoid them, see anything NPM has done ever.  With the rolling
release model of Guix, a package that the user relies on can break at
any time; it's better to play towards Guix strengths, among them roll-
backs.
FWIW you can already run Guix inside containers such as qemu or even
WSL, so apart from small technical hurdles, it shouldn't be hard to
deploy Guix on a proprietary system assuming the "end user" is
themselves a "dev".  However, in this picture, devs are not the end
users.  It is one thing to deploy Guix on their machine, but asking
them to deploy Guix on the machines of their "end users" (i.e. often
their clients), as is done e.g. by NPM is a totally different thing. 
For this, ironically, you need Guix as a system, and targeting Guix as
a system has little financial incentive to technically not ransomware
developers.

Cheers