Hi Ryan,

Perhaps Im being cynical but opening the doorway to lots of plug-and-play users 
atm could overwhelm the people heroically stabilising and smoothing out the OS.

Jonathan

March 19, 2022 1:21 AM, "Ryan Prior" <rpr...@protonmail.com 
(mailto:rpr...@protonmail.com?to=%22Ryan%20Prior%22%20<rpr...@protonmail.com>)> 
wrote:
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.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.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.wdyt?

Reply via email to