Nix Flakes and their Guix Equivalents

# Nix Flakes and their Guix Equivalents Source: [https://coopi.neocities.org/posts/nix-flakes-vs-guix](https://coopi.neocities.org/posts/nix-flakes-vs-guix) ## Table of Contents - [1\. Who is this for?](https://coopi.neocities.org/posts/nix-flakes-vs-guix#who-is-this-for_8dfe733ff63f) - [2\. What even is a flake, anyway?](https://coopi.neocities.org/posts/nix-flakes-vs-guix#what-even-is-a-flake-anyway_a2a3f30f9cbe) - [3\. Declaring dependencies: inputs vs\. channels](https://coopi.neocities.org/posts/nix-flakes-vs-guix#declaring-dependencies-inputs-vs-channels_a692cd1ee44c)- [3\.1\. Flakes:`inputs`](https://coopi.neocities.org/posts/nix-flakes-vs-guix#flakes-inputs_2a1b8a0bf6cb) - [3\.2\. Guix: channels](https://coopi.neocities.org/posts/nix-flakes-vs-guix#guix-channels_3f57fd4876b8) - [3\.3\. The comparison](https://coopi.neocities.org/posts/nix-flakes-vs-guix#the-comparison_138043686c9d) - [4\. Pinning dependencies: flake\.lock vs\. guix describe](https://coopi.neocities.org/posts/nix-flakes-vs-guix#pinning-dependencies-flake-lock-vs-guix-describe_e92c07680645)- [4\.1\. Flakes:`flake\.lock`](https://coopi.neocities.org/posts/nix-flakes-vs-guix#flakes-flake-lock_bc679b21a440) - [4\.2\. Guix:`guix describe`and`guix time\-machine`](https://coopi.neocities.org/posts/nix-flakes-vs-guix#guix-guix-describe-and-guix-time-machine_996bf8935b4b) - [4\.3\. The comparison](https://coopi.neocities.org/posts/nix-flakes-vs-guix#the-comparison_787a577d746f) - [5\. Purity: enforced isolation](https://coopi.neocities.org/posts/nix-flakes-vs-guix#purity-enforced-isolation_7327bd645516)- [5\.1\. Flakes: pure evaluation mode](https://coopi.neocities.org/posts/nix-flakes-vs-guix#flakes-pure-evaluation-mode_078261abdab0) - [5\.2\. Guix: purity by design](https://coopi.neocities.org/posts/nix-flakes-vs-guix#guix-purity-by-design_6eece251b1ca) - [5\.3\. The comparison](https://coopi.neocities.org/posts/nix-flakes-vs-guix#the-comparison_5b1016bbc923) - [6\. The output schema: what your project produces](https://coopi.neocities.org/posts/nix-flakes-vs-guix#the-output-schema-what-your-project-produces_4eb2c0e34d97)- [6\.1\. Flakes: structured outputs](https://coopi.neocities.org/posts/nix-flakes-vs-guix#flakes-structured-outputs_861c9428b553) - [6\.2\. Guix: first\-class records and modules](https://coopi.neocities.org/posts/nix-flakes-vs-guix#guix-first-class-records-and-modules_2f02e5f92476) - [6\.3\. The comparison](https://coopi.neocities.org/posts/nix-flakes-vs-guix#the-comparison_d8242e7c55a6) - [7\. Development environments: devShells vs\. manifests](https://coopi.neocities.org/posts/nix-flakes-vs-guix#development-environments-devshells-vs-manifests_6c78d1952c62)- [7\.1\. Flakes:`devShells`](https://coopi.neocities.org/posts/nix-flakes-vs-guix#flakes-devshells_41834ebf1a42) - [7\.2\. Guix:`guix shell`and manifests](https://coopi.neocities.org/posts/nix-flakes-vs-guix#guix-guix-shell-and-manifests_611de2ca11eb) - [7\.3\. The comparison](https://coopi.neocities.org/posts/nix-flakes-vs-guix#the-comparison_94a2f693cbe8) - [8\. System configuration:`nixosConfigurations`vs\.`operating\-system`](https://coopi.neocities.org/posts/nix-flakes-vs-guix#system-configuration-nixosconfigurations-vs-operating-system_a4393b2d5425)- [8\.1\. Flakes:`nixosConfigurations`](https://coopi.neocities.org/posts/nix-flakes-vs-guix#flakes-nixosconfigurations_aaaae3e9da61) - [8\.2\. Guix:`operating\-system`](https://coopi.neocities.org/posts/nix-flakes-vs-guix#guix-operating-system_1f7b57c06ced) - [8\.3\. The comparison](https://coopi.neocities.org/posts/nix-flakes-vs-guix#the-comparison_70a62dcfea51) - [9\. So what does Guix NOT have?](https://coopi.neocities.org/posts/nix-flakes-vs-guix#so-what-does-guix-not-have_452594b0a6e4)- [9\.1\. A standard project entry point](https://coopi.neocities.org/posts/nix-flakes-vs-guix#a-standard-project-entry-point_dc2f95bff316) - [9\.2\. A registry and quick\-install syntax](https://coopi.neocities.org/posts/nix-flakes-vs-guix#a-registry-and-quick-install-syntax_69ef3599a5db) - [9\.3\.`nix flake show`](https://coopi.neocities.org/posts/nix-flakes-vs-guix#nix-flake-show_77ccf50ddc24) - [10\. And what does Guix have that flakes don't?](https://coopi.neocities.org/posts/nix-flakes-vs-guix#and-what-does-guix-have-that-flakes-don-t_fa5eb2d2f2c4)- [10\.1\.`guix time\-machine`](https://coopi.neocities.org/posts/nix-flakes-vs-guix#guix-time-machine_50ecf8f7505e) - [10\.2\. Grafting](https://coopi.neocities.org/posts/nix-flakes-vs-guix#grafting_25642e0c8af7) - [10\.3\. First\-class package records](https://coopi.neocities.org/posts/nix-flakes-vs-guix#first-class-package-records_a5e6b2b734d5) - [10\.4\. Full\-source bootstrapping](https://coopi.neocities.org/posts/nix-flakes-vs-guix#full-source-bootstrapping_b7909c1af919) - [10\.5\. Channel authentication](https://coopi.neocities.org/posts/nix-flakes-vs-guix#channel-authentication_a0dde09ae0d2) - [11\. Summary table](https://coopi.neocities.org/posts/nix-flakes-vs-guix#summary-table_4437f31a716b) - [12\. So… who wins?](https://coopi.neocities.org/posts/nix-flakes-vs-guix#so-who-wins_a51dca8993ca) - [13\. Yes I actually cited my sources :3](https://coopi.neocities.org/posts/nix-flakes-vs-guix#yes-i-actually-cited-my-sources-3_5d45985a8ec7) I want to tell you a secret that took me WAY too long to internalize: there is no such thing as "the Guix equivalent of a flake\." I KNOW\!\! That sounds like a cop\-out\!\! But stick with me — it's actually the most interesting thing about this entire comparison\. Flakes are one big feature that solves a bunch of problems at once \([Dolstra, 2020](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_14)\)\. Guix solves those same problems, but it does so with a collection of smaller, orthogonal tools that were mostly in place*before*flakes even existed \([Contributors, 2025a](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_1)\)\. So the mapping isn't flake → ??? — it's flake → channels,*and*manifests,*and*`guix describe`,*and*`guix shell`,*and*`operating\-system`declarations,*and*… Okay I'm getting ahead of myself\. Let me set the stage first\. ## 1\.Who is this for? If you're a Nix person, you probably know Guix as "that other functional package manager, the one that uses Scheme\." You might have heard it described as a Nix fork — and there*is*shared lineage\! Guix reused the Nix daemon \(the C\+\+ component that handles build isolation and store management\) and builds everything else from scratch in Guile Scheme \([\(rekado\), 2019](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_20)\)\. The derivation format \(ATerm\) is shared \([Khana, 2026](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_15)\), the daemon lineage is shared, but the language, the package definitions, the service system, the whole world above the daemon — that's all Guix's own thing \([\(rekado\), 2020](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_21)\)\. If you're a Guix person, you've probably seen Nix people talking about "flakes" and wondered what the big deal is\. Maybe you've felt a tiny pang of — wait, do we not have that? Are we behind? The answer to both is: RELAX\!\! Guix has all of the*capabilities*that flakes provide\. It just delivers them in a different shape\. And understanding that shape is what this post is about\. ## 2\.What even is a flake, anyway? A brief primer for the Guix folks in the room\!\! \(Nix people, you can skim this — or maybe read it anyway, sometimes the refresher is nice :3\) A Nix flake is, at its core, just a source tree — typically a Git repository — that contains a file called`flake\.nix`in its root\. That's it\. The presence of`flake\.nix`is what makes it a flake \([Project, 2024](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_19)\)\. The file has a specific structure: ``` { # A human-readable description of what this flake provides. description = "A simple Go web server"; # Dependencies — other flakes, Git repos, tarballs. Nix fetches them, # evaluates them, and passes them to outputs. inputs = { # "github:NixOS/nixpkgs/nixos-unstable" means: fetch the nixos-unstable # branch from github.com/NixOS/nixpkgs nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable"; }; # outputs is a function. Its parameters are the resolved inputs (plus the # special "self" input, which is this flake itself). It returns an attrset of # things this flake provides. outputs = { self, nixpkgs }: let # Helper to generate outputs for multiple CPU architectures without # repeating yourself. Without this you'd need to write # packages.x86_64-linux, packages.aarch64-linux, etc. separately for every # single platform. supportedSystems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" ]; forAllSystems = nixpkgs.lib.genAttrs supportedSystems; in { # Packages this flake can build. nix build .#myapp looks here. The # <system> level is mandatory — flakes require explicit platform # targeting. packages = forAllSystems (system: let # Import nixpkgs for the current system. This gives us access to the # full nixpkgs package set — stdenv, buildGoModule, and ~120,000 other # packages [cite:@repology]. pkgs = nixpkgs.legacyPackages.${system}; in { # "default" means nix build . (without specifying a name) builds # this package. default = pkgs.buildGoModule { pname = "myapp"; version = "0.1.0"; src = ./.; # The entire git repo becomes the source }; }); # Development shells. nix develop looks here. Think: a reproducible # shell with all your build tools. devShells = forAllSystems (system: let pkgs = nixpkgs.legacyPackages.${system}; in { default = pkgs.mkShell { # These packages will be available in PATH inside the shell. buildInputs = with pkgs; [ go gopls gotools ]; }; }); }; } ``` Three moving parts: `description`A human\-readable string\. Self\-explanatory\.`inputs`Your dependencies — other flakes, Git repos, tarballs\. Nix fetches them, pins them, and passes them to your outputs function\.`outputs`A function that receives all the resolved inputs and produces a structured attrset of*things*— packages, dev shells, NixOS configurations, overlays, and so on \([Project, 2024](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_19)\)\.When you run any`nix`command against a flake, Nix also generates a`flake\.lock`— a JSON file that pins every input and their inputs, transitively, to exact revisions\. This lock file is what makes builds reproducible across machines and across time\. Flakes also enforce*pure evaluation*: no`$NIX\_PATH`, no`builtins\.currentSystem`, no environment variables leaking in\. Everything must be explicit \([Contributors, 2026](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_13)\)\. So, to summarize, flakes do roughly six things: 1. **Declare dependencies**\(`inputs`\) 2. **Pin dependencies**\(`flake\.lock`\) 3. **Enforce purity**\(no implicit state\) 4. **Provide a standard output schema**\(`packages`,`devShells`,`apps`,`nixosConfigurations`, etc\.\) 5. **Enable reproducible sharing**\(anyone can`nix build github:you/your\-repo`\) 6. **Define development environments**\(`devShells`\) Now here's the key insight: Guix already had solutions for most of these*before*flakes were introduced in Nix 2\.4 on November 1, 2021 \([Project, 2021](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_18)\)\. The channels mechanism landed in Guix around 2018–2019 \([Contributors, 2025a](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_1)\)\. And the solutions are*orthogonal*— you can use each one independently, without buying into a single monolithic abstraction\. Let's go through them one by one\!\! This is the fun part\!\! ## 3\.Declaring dependencies: inputs vs\. channels ### 3\.1\.Flakes:`inputs` In a flake, you declare your dependencies right there in`flake\.nix`: ``` inputs = { # Pull nixpkgs from the 25.11 release branch on GitHub nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.11"; home-manager = { url = "github:nix-community/home-manager"; # "follows" means: don't fetch home-manager's own nixpkgs input — use OUR # nixpkgs instead. This avoids having two copies of nixpkgs with different # versions, which is a common source of weird conflicts. inputs.nixpkgs.follows = "nixpkgs"; }; }; ``` Each input is another flake or a non\-flake source\. Nix fetches them all, evaluates them, and passes the results to your`outputs`function \([Project, 2024](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_19)\)\. ### 3\.2\.Guix: channels Guix has had[channels](https://guix.gnu.org/manual/en/html_node/Channels.html)since around 2018–2019 \([Contributors, 2025a](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_1)\)\. A channel is a Git repository containing Guile modules — typically package definitions, but also services, system configurations, or any Scheme code you want\. You declare your channels in`~/\.config/guix/channels\.scm`: ``` ;; channels.scm is a Scheme file that returns a list of channel records. Each ;; channel is a Git repository that Guix will fetch and compile. (list (channel (name 'guix) ; The official Guix channel (url "https://git.guix.gnu.org/guix.git") (branch "master")) (channel (name 'my-packages) ; Your personal channel (url "https://example.com/me/my-guix-packages.git") (branch "main"))) ``` Running`guix pull`fetches all channels, compiles them, and makes their modules available to every`guix`command\. This is your dependency resolution step\. Channels can declare dependencies on other channels using a`\.guix\-channel`file in the repo root \([Contributors, 2025b](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_2)\): ``` ;; .guix-channel — lives at the root of a channel repository. This tells Guix ;; that this channel depends on another channel called 'nonguix', so guix pull ;; will fetch both together. (channel (version 0) (dependencies (channel (name 'nonguix) (url "https://gitlab.com/nonguix/nonguix")))) ``` This is roughly analogous to`inputs`in a flake — one channel can pull in another\. When you`guix pull`, all transitive channel dependencies are fetched together\. ### 3\.3\.The comparison Both systems let you declare external dependencies and pull them in automatically\. The main differences: - Flakes are**per\-project**— each repo has its own`flake\.nix`with its own inputs\. Channels are**system\-wide**or per\-user — your`channels\.scm`applies to all`guix`invocations\. This means flakes naturally support different projects with different dependency sets, while with Guix, you'd typically use`guix time\-machine`or separate profiles to achieve the same effect\. - Flakes use a**URL\-like syntax**for references \(`github:NixOS/nixpkgs`,`git\+https://\.\.\.`\) while channels use**plain Git URLs**\. The flake syntax is more ergonomic for quick references, but channels are simpler and more explicit\. - Flakes support**non\-flake inputs**\(`flake = false;`\) for repos that don't contain a`flake\.nix`\. In Guix, a channel*is*just a Git repo with Scheme files — there's no special opt\-in required\. Any repo with Guile modules can be a channel\. ## 4\.Pinning dependencies: flake\.lock vs\. guix describe ### 4\.1\.Flakes:`flake\.lock` The lock file is a JSON graph\. Every input is pinned to an exact commit hash, and Nix verifies the`narHash`\(a hash of the full source tree\) against what it fetches \([Project, 2024](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_19)\)\. The lock file is committed to the repo, so anyone who clones it gets the exact same dependency versions\. ``` { "nodes": { "nixpkgs": { "locked": { "lastModified": 1712981134, "narHash": "sha256-...", "rev": "0d70582...", "type": "github" }, "original": { "id": "nixpkgs", "type": "indirect" } } }, "version": 7 } ``` `original`is what you asked for\.`locked`is what you*got*\. This two\-layer system means you can update selectively —`nix flake lock \-\-update\-input nixpkgs`updates only that one input while preserving everything else\. ### 4\.2\.Guix:`guix describe`and`guix time\-machine` When you run`guix pull`, Guix records the exact commits of all your channels\. Running`guix describe`shows you this information \([Contributors, 2025c](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_3)\): ``` Generation 42 Apr 14 2026 12:34:56 (current) guix 8a1ab32 repository URL: https://git.guix.gnu.org/guix.git branch: master commit: 8a1ab328e914e5dcfdeefb76a9651c7b68f1f032 my-packages a3b4c5d repository URL: https://example.com/me/my-guix-packages.git branch: main commit: a3b4c5d7e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4 ``` This is your lock file, essentially\. It lives in`~/\.config/guix/current`\(as a Guile profile\), not as a file in your project directory\. Now here's where it gets*really*interesting\. If you want to share a reproducible environment, you use`guix time\-machine`\([Contributors, 2025d](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_4)\): ``` # "--commit" pins Guix itself to a specific revision. "-- shell -m # manifest.scm" runs "guix shell" using that revision's package definitions. # The result: the exact same packages, always. guix time-machine --commit=8a1ab328 -- shell -m manifest.scm ``` This spins up a*specific historical revision of Guix itself*and runs the given command within it\. It downloads and compiles that revision if needed, creating an isolated environment where the package definitions are exactly the ones from that commit\. How cool is that?? I LOVE this feature so much it's honestly unreasonable\. There's also a pattern where you check a`channels\.scm`with pinned commits into your project repo: ``` ;; channels.scm — checked into the project repo. By pinning the commit, ;; anyone who checks out this repo and runs guix time-machine gets the exact ;; same Guix revision you used. (list (channel (name 'guix) (url "https://git.guix.gnu.org/guix.git") (commit "8a1ab328e914e5dcfdeefb76a9651c7b68f1f032"))) ``` ``` # Anyone can reproduce your exact environment with one command: guix time-machine -C channels.scm -- shell -m manifest.scm ``` ### 4\.3\.The comparison - `flake\.lock`is**per\-project**and**automatic**\.`guix describe`is**per\-user**and**automatic**, while`channels\.scm`with pinned commits is**per\-project**but**manual**\. Guix is working on making this more ergonomic, but the current workflow requires a bit more explicit setup for per\-project pinning\. - `flake\.lock`is a machine\-readable JSON graph\. Guix's equivalent is a Scheme file listing channels with commit hashes\. Both achieve the same goal, but the flake lock is more structured — it's a full dependency graph with`original`and`locked`entries for every transitive input\. - The`guix time\-machine`command is genuinely unique and has no direct flake equivalent\. It lets you travel to*any point in Guix's history*— not just to pinned dependency versions, but to a completely different state of the package collection \([Contributors, 2025d](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_4)\)\. This is incredibly powerful for reproducibility\. Like, you can run code from three years ago and it JUST WORKS?? That's wild\!\! ## 5\.Purity: enforced isolation ### 5\.1\.Flakes: pure evaluation mode Flakes run in a restricted evaluation context\.`builtins\.currentSystem`is forbidden\.`builtins\.getEnv`is forbidden\.`$NIX\_PATH`is ignored\. Everything must come from declared inputs \([Contributors, 2026](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_13)\)\. This is one of the best things about flakes — it makes it much harder to accidentally depend on implicit state\. The trade\-off is that it can be*frustrating*\. System detection requires explicit`system`parameters everywhere\. Reading environment variables is simply not possible\. Sometimes you really do want an impure escape hatch, and flakes make you work for it by passing`\-\-impure`explicitly\. ### 5\.2\.Guix: purity by design Guix doesn't need a "pure evaluation mode" because its evaluation is*already*pure by convention \([LWN\.net, 2024](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_16)\)\. Guile modules don't have access to environment variables unless you explicitly pass them in\. There's no equivalent of`$NIX\_PATH`— Guix resolves packages through its module system, not through a search path\.`builtins\.currentSystem`doesn't exist because there's no equivalent concept; you specify systems explicitly via package metadata and the`\-\-system`flag\. The build side is equally pure\. Builds run in isolated containers where only explicitly declared inputs are visible\. No`/usr/bin`, no`/etc`, no network access except for fixed\-output derivations\. This is shared with Nix — both systems use essentially the same sandboxing approach \([Contributors, 2025e](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_5)\)\. ### 5\.3\.The comparison Guix achieves purity through*architecture*— Scheme modules are inherently more contained than Nix's channel/path system\. Flakes achieve it through*enforcement*— a restricted evaluation mode layered on top of an otherwise impure system\. Both get you to the same place\. Guix's approach is arguably more elegant because it doesn't need to layer restrictions on top of something that was originally designed without them\. \(Though honestly, the fact that Nix managed to retrofit purity at all is kind of impressive — it's just a different philosophy of getting there\.\) ## 6\.The output schema: what your project produces ### 6\.1\.Flakes: structured outputs Flakes define a standard schema for their outputs \([Contributors, 2026](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_13)\)\. The ones you'll see most: OutputUsed by`packages\.<system\>\.<name\>``nix build``devShells\.<system\>\.<name\>``nix develop``apps\.<system\>\.<name\>``nix run``nixosConfigurations\.<name\>``nixos\-rebuild``overlays\.<name\>`Consumed by other flakes`nixosModules\.<name\>`Consumed by other flakes`formatter\.<system\>``nix fmt``templates\.<name\>``nix flake init``checks\.<system\>\.<name\>``nix flake check`This standardization is genuinely useful — it means`nix build \.`always knows where to look,`nix run`knows what to run, and`nix flake show`can give you a nice tree view of everything a flake provides\. The downside is that this schema is*rigid*\. You can't add arbitrary output types without modifying Nix itself, though there is a small extension mechanism\. And the`<system\>`parameter means you have to handle multi\-platform support explicitly — either with helper functions like`forAllSystems`or with libraries like`flake\-utils`or`flake\-parts`\. \(The system parameter thing is one of my least favorite parts of flakes — the boilerplate is REAL\.\) ### 6\.2\.Guix: first\-class records and modules Guix doesn't have a single "output schema" in the way flakes do\. Instead, it has*first\-class data types*that different commands know how to consume \([Contributors, 2025f](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_6)\): Guix conceptDefined asUsed byPackages`<package\>`records`guix install`,`guix build`ManifestsScheme files`guix shell \-m`,`guix package`System configs`operating\-system``guix system reconfigure`Home configs`home\-environment``guix home reconfigure`Services`<service\>`records`operating\-system``services`fieldChannelsGit repos`guix pull`Package variantsScheme procedures`\-\-with\-input`,`\-\-transform`A "Guix project" might provide some combination of: - A channel with package definitions \(like`packages\.<system\>\.<name\>`\) - A`manifest\.scm`for development \(like`devShells\.<system\>\.default`\) - A`system\.scm`for deployment \(like`nixosConfigurations\.<host\>`\) - An`operating\-system`or`home\-environment`declaration None of these require a special entry point file\. They're just Scheme files that define Scheme values\. You point the relevant`guix`subcommand at them and it knows what to do\. No ceremony, no schema validation — just Scheme all the way down\. Here's what a typical project might look like: ``` ;; manifest.scm — declares which packages your dev environment needs. ;; "specifications->manifest" takes a list of package names (strings) and ;; returns a manifest object. Think of it as your devShell. (specifications->manifest (list "guile" ; The Guile Scheme interpreter "guile-git" ; Guile bindings for libgit2 "guile-json")) ; JSON parsing for Guile ;; mylib.scm — a package definition. This is a <package> record, which is ;; Guix's equivalent of a Nix derivation but as a transparent, inspectable ;; data structure [cite:@guixpackages]. You can query its fields ;; programmatically — (package-name mylib), (package-version mylib), etc. (define-public mylib (package (name "mylib") (version "0.1.0") ;; "local-file" grabs files from the current directory at build time. In ;; Nix, this is like src = ./.; (source (local-file ".")) ;; gnu-build-system is the familiar ./configure && make && make install. ;; Guix has many others: cmake-build-system, python-build-system, etc. (build-system gnu-build-system) ;; Explicit list of dependencies. Unlike Nix, where stdenv provides gcc ;; and coreutils implicitly, Guix makes everything explicit. (inputs (list guile guile-git)) (home-page "https://example.com") (license gpl3+))) ``` ``` # Enter the dev environment — no flake needed, just point at the manifest guix shell -m manifest.scm # Build the package directly from its definition file guix build -f mylib.scm ``` ### 6\.3\.The comparison Flakes win on*discoverability*—`nix flake show`gives you a consistent view of everything a project provides\. Guix projects are more*ad\-hoc*: you need to know which files to look at, and there's no standard single\-entry\-point file\. \(Nix people will find this feels a bit… loose? But honestly it's fine once you get used to it\.\) Guix wins on*flexibility*— because everything is just Scheme, you can define whatever you want and compose it however you want\. There's no schema to conform to, no system\-parameter boilerplate\. The package definitions are transparent records, not opaque functions, which means you can inspect and transform them programmatically without any special tooling \([\(rekado\), 2019](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_20)\)\. This is genuinely so cool — packages are*data*, not functions, and you can do graph rewrites on them trivially\. The flake schema is also somewhat*NixOS\-centric*—`nixosConfigurations`,`nixosModules`,`darwinConfigurations`— while Guix's equivalents are just… more Scheme records \([Contributors, 2025g](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_7)\)\. The`operating\-system`declaration doesn't need a special output type because it*is*the standard way to define a system\. ## 7\.Development environments: devShells vs\. manifests ### 7\.1\.Flakes:`devShells` ``` # mkShell creates a derivation that, when "built", produces a shell environment. # All buildInputs end up in PATH. shellHook runs arbitrary bash when you enter # the shell. devShells.x86_64-linux.default = pkgs.mkShell { buildInputs = with pkgs; [ go gopls gotools ]; shellHook = '' echo "Welcome to the devShell!" ''; }; ``` You enter it with`nix develop`or`nix develop \.\#my\-shell`for named shells\. ### 7\.2\.Guix:`guix shell`and manifests ``` ;; manifest.scm — a list of package specification strings. ;; "specifications->manifest" resolves them from the available channels. (specifications->manifest (list "go" "gopls" "go-tools")) ``` You enter it with`guix shell \-m manifest\.scm`\([Contributors, 2025h](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_8)\)\. Or, for quick ad\-hoc environments where you don't even need a file: ``` guix shell go gopls go-tools ``` Guix also supports`\-\-container`for full isolation,`\-\-emulate\-fhs`for running programs that expect a standard Linux filesystem layout, and`\-\-nesting`for running Guix inside a Guix container \(\!\! recursive containers \!\!\) \([Contributors, 2025h](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_8)\)\. ### 7\.3\.The comparison Functionally very similar\!\! The main differences are: - Guix's manifests are standalone Scheme files, not embedded in a larger`flake\.nix`structure\. \(I like this — each file does one thing\.\) - `guix shell`can work without any file at all — just pass package names on the command line — while`nix develop`requires a flake or a`shell\.nix`for the legacy interface\. - Flakes give you named dev shells \(`devShells\.x86\_64\-linux\.test`,`devShells\.x86\_64\-linux\.default`\)\. Guix manifests are just files — you'd have`manifest\.scm`and`test\-manifest\.scm`side by side\. - Both support containerized development, and both are great for it\. ## 8\.System configuration:`nixosConfigurations`vs\.`operating\-system` ### 8\.1\.Flakes:`nixosConfigurations` ``` # nixosSystem takes a list of NixOS modules and produces a full system # derivation — kernel, services, config files, everything. You deploy with: # nixos-rebuild switch --flake .#myhost nixosConfigurations.myhost = nixpkgs.lib.nixosSystem { system = "x86_64-linux"; modules = [ ./configuration.nix ; Your system config home-manager.nixosModules.home-manager ; Home Manager module ]; }; ``` The`nixosSystem`function takes a list of NixOS modules \(which use the module system with`options`and`config`and priority\-based merging via`mkIf`,`mkDefault`,`mkForce`\) and produces a full system derivation\. ### 8\.2\.Guix:`operating\-system` ``` ;; This is a Scheme record — a data structure, not a function. Every field is a ;; named, typed value that Guix validates [cite:@guixoperatingsystem]. You ;; deploy with: guix system reconfigure config.scm (operating-system (host-name "myhost") (timezone "Etc/UTC") ;; Bootloader configuration — Guix supports GRUB, U-Boot, etc. (bootloader (bootloader-configuration (bootloader grub-efi-bootloader) (target "/boot/efi"))) ;; File systems are declared as a list. %base-file-systems provides sensible ;; defaults for /dev, /proc, /sys, etc. (file-systems (cons (file-system (device "/dev/sda1") (mount-point "/") (type "ext4")) %base-file-systems)) ;; Services form a directed acyclic graph (DAG). Each service can extend ;; other services [cite:@guixservices]. %base-services provides the ;; essentials: Shepherd (the init system), syslog, networking, etc. (services (cons (service openssh-service-type) %base-services))) ``` No special "output type" needed — you just point`guix system`at a file that returns an`operating\-system`record\. It's just Scheme\. Always just Scheme\. :3 ### 8\.3\.The comparison Both approaches are declarative and reproducible\. The philosophical difference is that NixOS configuration uses a*module system*with`options`,`config`,`mkIf`,`mkMerge`, and priority\-based merging — multiple modules can set the same option and the system resolves priorities\. Guix uses*Scheme records and service composition*— a DAG of service extensions where any service can extend any other service, and the extensions are composed programmatically via Scheme functions \([Contributors, 2025i](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_9)\)\. They're both excellent approaches, and each has strengths the other lacks\. NixOS's module system makes it easy to have dozens of modules all contributing to the same configuration without conflicts\. Guix's service composition makes it trivial to write a new service that hooks into the existing system in arbitrary ways\. ## 9\.So what does Guix NOT have? I want to be honest here — not everything is a perfect mapping\. There are a few things flakes provide that Guix currently doesn't match cleanly: ### 9\.1\.A standard project entry point Flakes have`flake\.nix`— one file that declares dependencies, defines outputs, and provides a discoverable schema\. There's nothing stopping you from finding`flake\.nix`and understanding the project's structure at a glance\. Guix projects are more convention\-based\. You might find`manifest\.scm`,`channels\.scm`,`guix\.scm`,`package\.scm`, or something else entirely\. There's been some movement toward standardizing`guix\.scm`as a project file that`guix shell`picks up automatically \([Contributors, 2025h](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_8)\), but it's not as established as`flake\.nix`\. ### 9\.2\.A registry and quick\-install syntax Flakes have a[global registry](https://github.com/NixOS/flake-registry)that maps short names to URLs \([Project, 2024](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_19)\): ``` nix run nixpkgs#hello nix build github:NixOS/nixpkgs#firefox ``` Guix uses package specifications for similar ergonomics: ``` guix shell hello guix install firefox ``` But there's no equivalent of the registry for pointing at arbitrary Git repos by short name\. You just use the URL\. Honestly I think this is fine — the registry has been a source of confusion in the Nix world, since it's not always clear whether`nixpkgs`refers to the registry entry, a local path, or something else\. ### 9\.3\.`nix flake show` The`nix flake show`command is genuinely nice — it gives you a tree view of everything a flake provides \([Contributors, 2026](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_13)\)\. Guix has`guix search`for packages and`guix system search`for services, but there's no equivalent of "show me everything this project/repo provides\." You just look at the Scheme files\. ## 10\.And what does Guix have that flakes don't? Fairness demands I mention the flip side\!\! There are some REALLY cool things in Guix that flakes don't have: ### 10\.1\.`guix time\-machine` I mentioned this earlier, but it deserves emphasis\. The ability to say "run this command as if it were any arbitrary date in Guix's history" is*incredibly*powerful for reproducibility \([Contributors, 2025d](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_4)\)\. Flakes can pin dependencies, but you can't easily say "run this with the version of nixpkgs from six months ago" without manually finding and specifying the commit\. With Guix,`guix time\-machine \-\-commit=\.\.\. \-\-`does exactly this\. I love this feature SO MUCH\!\! ### 10\.2\.Grafting Guix has a feature called[grafting](https://guix.gnu.org/manual/en/html_node/Security-Updates.html)that lets it apply security updates to the dependency tree*without*rebuilding every dependent package \([Contributors, 2025j](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_10)\)\. When a low\-level library like glibc has a vulnerability, Guix can swap in the fixed version by rewriting store paths\. Nix rebuilds everything\. For a large dependency tree, the difference can be*hours*of build time\. This is a HUGE advantage\. ### 10\.3\.First\-class package records In Nix, packages are functions — you call`stdenv\.mkDerivation \{ \.\.\. \}`and it returns a derivation, which is an opaque attribute set\. In Guix, packages are`<package\>`records — transparent data structures with named fields that you can inspect, transform, and compose with standard Scheme procedures \([Contributors, 2025f](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_6)\)\. This means you can do things like: ``` ;; package-input-rewriting walks the entire dependency graph and replaces every ;; occurrence of 'perl' with 'perl-minimal'. Try doing that in one line with ;; Nix!! (package-input-rewriting `((,perl . ,perl-minimal))) ;; The 'inherit' keyword works like inheriting from a parent class — you get all ;; the fields of 'coreutils' but override just the ones you specify. (package (inherit coreutils) (arguments (substitute-keyword-arguments (package-arguments coreutils) ((#:tests? _ #f) #f)))) ``` Graph rewriting is*trivial*in Guix because packages are data, not functions \([\(rekado\), 2019](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_20)\)\. Nix has overlays for a similar purpose, but they're less ergonomic because the opaque function interface makes inspection and transformation harder\. ### 10\.4\.Full\-source bootstrapping Guix is obsessive about[bootstrapping from source](https://guix.gnu.org/manual/en/html_node/Bootstrapping.html)\([Contributors, 2025k](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_11)\)\. The entire system can be built from a tiny trusted computing base — a ~​500\-byte hex assembler, then the`mes`C compiler written in Scheme, then`tcc`, then the full GNU toolchain, and up from there \([\(janneke\) Nieuwenhuizen, 2023](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_17)\)\. The[bootstrappable builds](https://bootstrappable.org/)project has the details and it is WILD\. Nix relies on more binary seeds\. This matters for trust and verifiability — if you can't audit the bootstrap chain, you can't truly verify that your system was built from the sources you think it was\. ### 10\.5\.Channel authentication Guix channels support[cryptographic authentication](https://guix.gnu.org/manual/en/html_node/Channel-Authentication.html)out of the box \([Contributors, 2025l](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_12)\)\. Each channel specifies an "introduction" — a specific commit and its Ed25519 signature — and Guix verifies the full chain of signatures from that introduction to the current commit\. Flakes use HTTPS and GitHub's infrastructure for trust, which is a different and arguably less rigorous security model\. ## 11\.Summary table Because what's a comparison post without a summary table\. \(If you skip straight here… I see you\. But fair enough, this is the good part\.\) CapabilityNix \(flakes\)GuixDependency declaration`inputs`in`flake\.nix``channels\.scm`\+`\.guix\-channel`\([Contributors, 2025a](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_1)\)Dependency pinning`flake\.lock`\(automatic, per\-project\)`guix describe`\(auto, per\-user\) \+`channels\.scm`with commits \(manual, per\-project\) \([Contributors, 2025c](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_3)\)Pure evaluationEnforced in flake mode \([Contributors, 2026](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_13)\)Inherent by design \([LWN\.net, 2024](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_16)\)Output schemaStructured attrset in`outputs`Scheme records \(ad\-hoc\) \([Contributors, 2025f](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_6)\)Dev environments`devShells`\+`nix develop``manifest\.scm`\+`guix shell`\([Contributors, 2025h](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_8)\)System configuration`nixosConfigurations`\+ module system`operating\-system`\+ service DAG \([Contributors, 2025g](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_7)\)One\-command reproducibility`nix build github:foo/bar``guix time\-machine \-C channels\.scm \-\- build`\([Contributors, 2025d](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_4)\)Per\-project pinningAutomatic \(`flake\.lock`\)Manual \(`channels\.scm`with commit\)Discoverability`nix flake show`\([Contributors, 2026](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_13)\)Scheme module inspectionPackage modelOpaque functionsTransparent records \([\(rekado\), 2019](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_20)\)Init systemsystemdGNU Shepherd \([Contributors, 2025i](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_9)\)Security updatesFull rebuildGrafting \(fast\) \([Contributors, 2025j](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_10)\)Bootstrap trustBinary seedsFull\-source bootstrap \([\(janneke\) Nieuwenhuizen, 2023](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_17)\)Authenticated updatesHTTPS/GitHub trustEd25519 channel authentication \([Contributors, 2025l](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_12)\)FHS support`buildFHSUserEnv``\-\-emulate\-fhs`\([Contributors, 2025h](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_8)\)Non\-Linux supportmacOS \(nix\-darwin\)GNU Hurd \([Contributors, 2025g](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_7)\)Free software onlyNo \(configurable\)Yes \(FSDG compliant\) ## 12\.So… who wins? NOBODY\!\! That's the point\!\! Flakes and Guix's mechanisms are solving the same*class*of problems — reproducibility, dependency management, system declaration — with different architectural philosophies\. Flakes are a monolithic feature: one file, one schema, one lock file, one set of conventions \([Project, 2024](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_19)\)\. Guix is a collection of orthogonal tools: channels for distribution \([Contributors, 2025a](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_1)\), manifests for environments \([Contributors, 2025h](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_8)\),`operating\-system`for configuration \([Contributors, 2025g](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_7)\),`guix time\-machine`for reproducibility \([Contributors, 2025d](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_4)\), and Scheme records for everything else \([Contributors, 2025f](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_6)\)\. If you like having One Standard Way to do things — one entry point file, one output schema, one lock format — flakes will feel natural\. If you prefer composing small, independent tools that each do one thing well — the Unix philosophy applied to package management — Guix will feel like home\. And honestly? Both are incredible achievements \([LWN\.net, 2024](https://coopi.neocities.org/posts/nix-flakes-vs-guix#citeproc_bib_item_16)\)\. The fact that we have*two*thriving ecosystems built around the idea that package management should be functional, declarative, and reproducible is a*good thing*\. There's no rivalry here — just two different implementations of a genuinely revolutionary idea, each pushing the other forward\. Now if you'll excuse me, I need to go meow at my cats about service composition DAGs\. They don't care but I NEED to tell SOMEONE\. ## 13\.Yes I actually cited my sources :3 I know, I know — you're reading a blog post on Neocities by a feral catperson on the net, and suddenly there's a*bibliography*at the bottom\. Trust me, I'm as surprised as you are\!\! But I wanted to get this right, so I read the manuals, the wikis, the mailing list threads, the Hacker News comments from actual Guix co\-maintainers, and like three years of blog posts about bootstrapping\. The things I do for a blog post\. Contributors, GNU Guix \(2025a\)\.*Channels –\- gnu guix reference manual*\. GNU Guix Reference Manual, version 1\.5\.0\.[https://guix\.gnu\.org/manual/en/html\_node/Channels\.html](https://guix.gnu.org/manual/en/html_node/Channels.html)\. Contributors, GNU Guix \(2025b\)\.*Declaring channel dependencies –\- gnu guix reference manual*\. GNU Guix Reference Manual, version 1\.5\.0\.[https://guix\.gnu\.org/manual/en/html\_node/Declaring\-Channel\-Dependencies\.html](https://guix.gnu.org/manual/en/html_node/Declaring-Channel-Dependencies.html)\. Contributors, GNU Guix \(2025c\)\.*Invoking guix describe –\- gnu guix reference manual*\. GNU Guix Reference Manual, version 1\.5\.0\.[https://guix\.gnu\.org/manual/en/html\_node/Invoking\-guix\-describe\.html](https://guix.gnu.org/manual/en/html_node/Invoking-guix-describe.html)\. Contributors, GNU Guix \(2025d\)\.*Invoking guix time\-machine –\- gnu guix reference manual*\. GNU Guix Reference Manual, version 1\.5\.0\.[https://guix\.gnu\.org/manual/en/html\_node/Invoking\-guix\-time\_002dmachine\.html](https://guix.gnu.org/manual/en/html_node/Invoking-guix-time_002dmachine.html)\. Contributors, GNU Guix \(2025e\)\.*Substitutes –\- gnu guix reference manual*\. GNU Guix Reference Manual, version 1\.5\.0\.[https://guix\.gnu\.org/manual/en/html\_node/Substitutes\.html](https://guix.gnu.org/manual/en/html_node/Substitutes.html)\. Contributors, GNU Guix \(2025f\)\.*Defining packages –\- gnu guix reference manual*\. GNU Guix Reference Manual, version 1\.5\.0\.[https://guix\.gnu\.org/manual/en/html\_node/Defining\-Packages\.html](https://guix.gnu.org/manual/en/html_node/Defining-Packages.html)\. Contributors, GNU Guix \(2025g\)\.*Operating\-system reference –\- gnu guix reference manual*\. GNU Guix Reference Manual, version 1\.5\.0\.[https://guix\.gnu\.org/manual/en/html\_node/operating\_002dsystem\-Reference\.html](https://guix.gnu.org/manual/en/html_node/operating_002dsystem-Reference.html)\. Contributors, GNU Guix \(2025h\)\.*Invoking guix shell –\- gnu guix reference manual*\. GNU Guix Reference Manual, version 1\.5\.0\.[https://guix\.gnu\.org/manual/en/html\_node/Invoking\-guix\-shell\.html](https://guix.gnu.org/manual/en/html_node/Invoking-guix-shell.html)\. Contributors, GNU Guix \(2025i\)\.*Defining services –\- gnu guix reference manual*\. GNU Guix Reference Manual, version 1\.5\.0\.[https://guix\.gnu\.org/manual/en/html\_node/Defining\-Services\.html](https://guix.gnu.org/manual/en/html_node/Defining-Services.html)\. Contributors, GNU Guix \(2025j\)\.*Security updates –\- gnu guix reference manual*\. GNU Guix Reference Manual, version 1\.5\.0\.[https://guix\.gnu\.org/manual/en/html\_node/Security\-Updates\.html](https://guix.gnu.org/manual/en/html_node/Security-Updates.html)\. Contributors, GNU Guix \(2025k\)\.*Bootstrapping –\- gnu guix reference manual*\. GNU Guix Reference Manual, version 1\.5\.0\.[https://guix\.gnu\.org/manual/en/html\_node/Bootstrapping\.html](https://guix.gnu.org/manual/en/html_node/Bootstrapping.html)\. Contributors, GNU Guix \(2025l\)\.*Channel authentication –\- gnu guix reference manual*\. GNU Guix Reference Manual, version 1\.5\.0\.[https://guix\.gnu\.org/manual/en/html\_node/Channel\-Authentication\.html](https://guix.gnu.org/manual/en/html_node/Channel-Authentication.html)\. Contributors, NixOS Wiki \(2026\)\.*Flakes –\- nixos wiki*\. Official NixOS Wiki\.[https://wiki\.nixos\.org/wiki/Flakes](https://wiki.nixos.org/wiki/Flakes)\. Dolstra, Eelco \(2020\)\.*Nix flakes, part 1: An introduction and tutorial*\. Tweag Blog\.[https://tweag\.io/blog/2020\-05\-25\-flakes/](https://tweag.io/blog/2020-05-25-flakes/)\. Khana, Firas Khalil \(2026\)\.*The guix nix abomination: Leveraging guix derivations in nix*\. Blog post\.[https://fzakaria\.com/2026/06/05/the\-guix\-nix\-abomination\-leveraging\-guix\-derivations\-in\-nix](https://fzakaria.com/2026/06/05/the-guix-nix-abomination-leveraging-guix-derivations-in-nix)\. LWN\.net \(2024\)\.*A look at nix and guix*\. LWN\.net\.[https://lwn\.net/Articles/962788/](https://lwn.net/Articles/962788/)\. \(janneke\) Nieuwenhuizen, Jan \(2023\)\.*The full\-source bootstrap: Building from source all the way down*\. GNU Guix Blog\.[https://guix\.gnu\.org/en/blog/2023/the\-full\-source\-bootstrap\-building\-from\-source\-all\-the\-way\-down/](https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/)\. Project, NixOS \(2021\)\.*Release 2\.4 \(2021\-11\-01\)*\. Nix Release Notes\.[https://nix\.dev/manual/nix/stable/release\-notes/rl\-2\.4](https://nix.dev/manual/nix/stable/release-notes/rl-2.4)\. Project, NixOS \(2024\)\.*Nix flakes reference manual –\- command: nix flake*\. Nix Reference Manual\.[https://nix\.dev/manual/nix/stable/command\-ref/new\-cli/nix3\-flake](https://nix.dev/manual/nix/stable/command-ref/new-cli/nix3-flake)\. \(rekado\), Ricardo Wurmus \(2019\)\.*Guix co\-maintainer comment on guix/nix relationship*\. Hacker News comment\.[https://news\.ycombinator\.com/item?id=18910683](https://news.ycombinator.com/item?id=18910683)\. \(rekado\), Ricardo Wurmus \(2020\)\.*Comment on guix daemon provenance*\. Hacker News comment\.[https://news\.ycombinator\.com/item?id=25191466](https://news.ycombinator.com/item?id=25191466)\.