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

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

[Ryan Prior]

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 3209 bytes --]

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

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

[Jonathan McHugh]

[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]

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" <rprior@protonmail.com (mailto:rprior@protonmail.com?to=%22Ryan%20Prior%22%20<rprior@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?

[-- Attachment #2: Type: text/html, Size: 3487 bytes --]

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

[zimoun]

Hi,

> 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.

Today, Guix provides a script that allows to install on any foreign
Linux distribution.  Somehow, it is already “Guix for Desktop”, no? ;-)

Guix provides a “nightly“ VM.  And, IIRC, Guix is also available via
upstream Gnome boxes. Somehow, it is already “Guix for Desktop”, no? ;-)

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”.

Could you elaborate?


Cheers,
simon

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

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
> 

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

[zimoun]

Hi Ryan,

Thank you for your detailed explanations.  Here I try to connect the
dots between the current blocks and the picture you are drawing.


On Sat, 19 Mar 2022 at 18:18, Ryan Prior <rprior@protonmail.com> wrote:

> 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.

From my experience about Docker, Guix on foreign Linux distro via the
install script provides the same experience as Docker for Desktop.

For sure, the learning curve is not the same.  Because Guix is less
polished and many less tutorials are around.


About MacOs and Windows, well Docker is powered by a company so their
product is targeting a market.  Instead, Guix is powered by volunteers
working on their personal interest; well if a company is ready to invest
in Guix, I am sure it would also “work” on these platforms. ;-)


> 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.

Well, the user manages the Dockerfile build, no?

Guix on foreign distro works the same way, no?  Instead of a Dockerfile,
it is a config.scm file.

Somehow, the workflow of Docker and Guix-on-foreign-distro is the same
from my point of view.  The main difference is robustness and
documentation, again IMHO.


> 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 agree.  About Windows, Guix should be available via WSL2, IIURC.
About MacOS… long story. ;-)


> 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.

What I miss is that your description maps one to one my use of Guix on
foreign distro with “collaborators” (mainly biologists, so similar to
the end-users described above, I guess).  Whatever their Linux distro
and their host versions are (usually Ubuntu though), we are running the
same computational stack; mainly:

    guix time-machine -C channels.scm -- shell -m manifest.scm

where channels.scm and manifest.scm live in a shared Git repo with the
other stuff.  In this case, manifest.scm provides the tools for
building, say manually.

It is similar with

    guix time-machine -C channels.scm -- build -f my-app.scm

using the Guix daemon for building.

And channels.scm can contain private collections not yet in Guix.


> 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.

For instance, I have never used “guix system reconfigure” for my daily
job. :-)

On any Linux distribution,

    guix shell -C coreutils

does what you are describing.  No VM, only Linux namespace.

For sure, it leads to issues for MacOS.  Well, long story. :-)

>
> 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.

I agree.  Well, Guix via Gnome boxes seems a step in that direction.  I
also agree that the story of Guix for Windows and MacOS is not so nice.
Currently, it is a strong limitation for adoption in my lab; most if not
all people run the main computer with MacOS or Windows and another
dedicated computer for “computational analysis”.

About Windows, it could be worth to maybe document what already
works. :-)


Cheers,
simon

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

[Zhu Zihao]

[-- Attachment #1: Type: text/plain, Size: 2831 bytes --]


Make Guix available on Windows platform will be a painful job.

1. Windows doesn't allow user to create symbolic link without admin
permission, which guix use intensely.

2. There's no RUNPATH for Windows DLL, so all dynamic library
dependencies should in the same directory to allow Windows find it.

3. Many developers on Guix, but less developer on Guile. I post some thread on guile-devel,
but there's few people will reply me. And the Windows support of Guile 3
is still missing.


Ryan Prior <rprior@protonmail.com> writes:

> 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?


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

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

[Josselin Poiret]

Hello everyone,

Just a small comment stemming from my time fiddling with Win32 API and
friends.

Zhu Zihao <all_but_last@163.com> writes:
> 2. There's no RUNPATH for Windows DLL, so all dynamic library
> dependencies should in the same directory to allow Windows find it.

There actually is an analogue for RUNPATH, because Windows applications
often vendor DLLs, and need a way to manipulate where they are loaded
from.  You can get a similar result using assembly manifests, see [1].

[1] https://docs.microsoft.com/en-us/windows/win32/sbscs/assembly-manifests

Best,
-- 
Josselin Poiret

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

[Aurora]

Zhu Zihao <all_but_last@163.com> writes:

> Make Guix available on Windows platform will be a painful job.
>
> 1. Windows doesn't allow user to create symbolic link without admin
> permission, which guix use intensely.
>
> 2. There's no RUNPATH for Windows DLL, so all dynamic library
> dependencies should in the same directory to allow Windows find it.
>

I think it's worth noting that the use of VM-based mechanisms in a
similar way to Docker for Desktop, suggested in the OP, would limit
these issues somewhat.

Native Guix would be exactly as troublesome as you suggest.

It might be possible to just rely on WSL.