So you can for example use WSL2 on Windows with a small Linux distribution and then extract the guix binaries from the website guix.gnu.org onto there, start guix-daemon in there and use guix like that. That said, I care about bootstrappable builds, so I can't recommend using a hypervisor I can't trust (Windows Hyper-V) as a base.
That's if you want the development environment.
On the other hand, for using guix packs of your software, you don't even need to install guix. Just unpack the pack as-is (or use docker).
Note: guix supports cross compilation, so you CAN just use --target=x86_64-w64-mingw32 and it will compile your program for Windows native just fine. The computer that is doing the building needs to be Linux- or Hurd-based, though.
Sometimes people come and try to port guix to cygwin or whatever but I have no experience in how far that is.
> Perhaps some day this will also be possible for Guix, but I don't think it fits the ideology of Guix since MacOS isn't free (not as in beer).
I just wanna note here that the hesitation to invest in macOS support in the Guix development community is technical as well as ideological. macOS is a difficult platform to support for third-party package managers, and developer interest in macOS support is a difficulty within the Nix community, too. There's a lot of breakage on major macOS upgrades as well as some fundamental portability and hermeticity problems on the platform.
That said, (as an outsider) I think it would be awesome if Guix ran on macOS, just like it's ultimately a good thing for the world and for GNU that Emacs runs pretty well on macOS.
I've had some luck in building it on MacOS with brew, however, the investment of learning MacOS dynamic linker is too costly at the moment, and it seems to be a blocking issue right now
There seems to be a lot of Mac hackers on HN! Maybe comments like yours will eventually inspire someone with the chops to play around and advance things.
Slight nitpick, Nix does support more architectures, but those are the ones with prebuilt packages. Compiling say 32 bit ARM is quite feasible, takes roughly a day for a full OS image.
This is the only reason I haven't tried to use Guix. I love the concept, I want to use it, but it does not run on FreeBSD. And I would not invest time in a packaging system that works on my workstation but not on my servers.
It is sad to see so many Linux only software, especially when there is no technical reason not to support *BSD.
> when there is no technical reason not to support BSD.
Guix' packages include glibc in their dependency chain, so unless you can use glibc on BSD, there is your technical reason. For example GNU Hurd is supported in addition to Linux.
I feel this. My love for BSD almost matches my love for Nix, it's unfortunate I have to choose one or the other.
I'm aware Nix is closely integrated with SystemD, so availability on BSD will probably never happen (though perhaps you could use the Darwin code as a starting point?), but I'd be curious to know what in particular limits Guix from being ported.
Wait it's integrated with SystemD? What is a package management system doing with the init process? I now remember that Guix is a daemon, something that made me really wary at the time; but a SystemdD dependency is something else entirely.
NixOS can be validly viewed as a very fancy Systemd configuration toolkit.
If you think about it, ultimately an instance of a modern general-purpose OS is structured as a set of services which are described for and orchestrated by, well, something. In the case of NixOS (not Nix in general!) that something is Systemd (which also happens to be used by all other major Linux distros); in the case of GuixSD that something is GNU Shepherd (which also happens to be used by GNU Hurd)
Nix is also generally run as a daemon. It doesn't have a dependency on systemd and it does run on MacOS. I think also it runs on FreeBSD in principle.
The parent poster was probably conflating NixOS and Nix. NixOS is a way of using nixpkgs to build/configure and install/upgrade an operating system based on Linux and systemd. But you are not obligated to use systemd just because you're using nixpkgs.
NixOS uses sytemd for essentially the same reason other Linux distributions do: most user environments are now built with the assumption that systemd underlies them if Linux does as well. In principle you could fork nixpkgs and make all the necessary changes to remove the systemd assumption - managing a NixOS system and hacking on nixpkgs are basically the same skillset so it's not like managing an Ubuntu system where you would have to become familiar with how Ubuntu gets built. With nixos, the command is the same whether you're building an entirely new distribution based on a custom fork or whether you're just downloading builds of the latest security upgrades. Aside from the actual energy it takes to maintain a second system manager, you would only have to wait for the builds to complete rather than learning how to build everything. But so far no-one who has tried that has got enough traction - the cost-benefit just isn't there. Honestly, I think this is part of the reason people are offended by NixOS in particular using systemd: it feels like it should be possible for you to remove the systemd dependency, but you haven't done it.
