From: Zhu Zihao <all_but_last@163.com>
To: Ryan Prior <rprior@protonmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)
Date: Sun, 20 Mar 2022 16:04:00 +0800 [thread overview]
Message-ID: <86sfrdxcwy.fsf@163.com> (raw)
In-Reply-To: <BJz4w-Dvq4U6hET3MMciG3iE_J_W9Af-JDz54zawfcu2lDSfqodxURmyFJ8cMBN-7_MCTo5lxFXQV_GeewbHMLU5HQmpqEw9m7ad4SFA43I=@protonmail.com>
[-- 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 --]
next prev parent reply other threads:[~2022-03-20 8:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-19 0:20 Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works) Ryan Prior
2022-03-19 9:06 ` Liliana Marie Prikler
2022-03-19 10:27 ` Jonathan McHugh
2022-03-19 13:21 ` zimoun
2022-03-19 18:18 ` Ryan Prior
2022-03-19 22:57 ` Yasuaki Kudo
2022-03-21 10:26 ` zimoun
2022-03-20 8:04 ` Zhu Zihao [this message]
2022-03-20 10:47 ` Josselin Poiret
2022-03-20 15:15 ` Aurora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86sfrdxcwy.fsf@163.com \
--to=all_but_last@163.com \
--cc=guix-devel@gnu.org \
--cc=rprior@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).