Guix for Development(dthompson.us) |
Guix for Development(dthompson.us) |
https://guix.gnu.org/cookbook/en/html_node/Software-Developm...
The idea was to show that there are several "levels" to take advantage of Guix for development, where the `guix.scm` file in David Thompson's blog post is the first level.
Sprites[0], exe.dev[1], and more services seem to be focusing on providing instant VMs for these use cases, but for me it seems like it's a waste for users to have to ssh into a separate cloud server (and feel the latency) just to get a clean dev environment. I feel that a similar tool where you can get a clean slate dev environment from a declarative description locally, without all of the overhead and the weight of Docker or VMs would be very welcomed.
(Note: I am not trying to inject AI-hype on a Guix-related post, I do realize that the audience of LLM tools and Guix would be quite different, this is just an observation)
[0]: https://sprites.dev
[1]: https://exe.dev
https://guix.gnu.org/manual/1.5.0/en/html_node/Miscellaneous...
I've never felt the need myself. If something is missing, I add it and I think that is the real fun in running Guix because creating your own well defined package or service is deeply rewarding.
Anyway, you can find people using it in the wild either by search engine[1] or with Toys[2] which is also handy for finding examples of missing packages too.
[1]: https://duckduckgo.com/?t=fpas&q=%22config.scm%22+nix-servic...
I've been running GNU Guix for five years now, after lots of distro hopping, including to and from NixOS. I left Nix because I found the documentation (particularly regarding the language) to be a struggle to work with (though I imagine it's improved since then).
GNU Guix + nonguix + flatpak is perfectly suitable for everyday use.
(a) evaluation is eager
(b) lots of variable mutation.
But perhaps lazy evaluation and lack of variable mutation in guix scheme is not such a problem after all for a nix _like_ system -- I don't know.
1. https://www.gnu.org/software/guile/manual/html_node/Expressi...
2. https://guix.gnu.org/manual/1.5.0/en/guix.html#G_002dExpress...
I don't even disagree that nonfree software is bad, but blaming the users who often have no choice in the matter (e.g. drivers) is the wrong way to go.
These days with a la carte access to all of the container ecosystem primitives as nice, ergonomic, orthogonal operations I don't really see the value in nixpkgs. Don't really see the value in a container registry either: a correctly attested content addressable store with some DNS abbreviations is 100 lines of code because mostly it's git and an S3 shim.
The category error at the heart of nixpkgs is that the environment in which software is compiled need resemble the environment in which it executes. Silly stuff. So whether you're a patchelf --rpath ... Person or an unshare --bind-mount Enjoyer (isomorphic), just remember, in 2026 the guy with the daemon that runs as root does not want you to have nice things.
In Nix, this is a single flag. In Guix, you either deploy with all libraries on a custom /guix path, or nothing.
https://guix.gnu.org/manual/1.5.0/en/html_node/Invoking-guix...
I agree, for local development docker is often overkill.
However, for production it's absolutely not overkill. And since pretty much all projects are intended for production at some point, they'll need a Dockerfile and docker compose or some other equivalent.
And at that point, you're maintaining the Dockerfile anyway, so why not use it for local dev as well? That way your dev and production environments can be close to identical.
Guix looks nice - probably nicer than docker for dev work. But is it nice enough to justify maintaining two separate systems and have your dev and production diverge?
The general philosophy of Guix is to have a single definition for how to build your software and use it for the entire dev to production pipeline.
[1]: https://guix.gnu.org/manual/1.5.0/en/html_node/Invoking-guix...
As a side benefit, the generated docker image can be very tiny.
It’s regrettable that this is necessary, but with so few Ethernet ports on laptops it’s harder to install these things without access to WiFi.
LLMs have also made writing syntacticly correct Nix scripts much easier, so I don't miss Guix's Guile that much.
Writing a package is not as bad as it sounds, nix and guix have very little difference between "package maintainer" and "user" so most users probably can package software. Normally copying something from nixpkgs or similar will get you most the way there.
Docker is, as the article describes, just a bandaid and the symptom of unthoughful development foundations.
In the long term, Guix may win out. Probably not in my life time though. But it's a win for developers, and nix really isn't so bad with everyone vibecoding away it's complexity anyways.
But i woudn't expect less from some hijackers.
Proof:
https://donate.stripe.com/8x2bJ133ia2H3Zw4j38N201
but the attitude has been changing recently from active shaming for even mentioning non-free stuff, to passive acceptance of pragmatically pointing a newcomer to nonguix.
Are they found in any laptop that is reasonably available on the market?
I don't think that Guix is punishing users by not supporting non-libre hardware. They are making a choice in what they develop and anybody of similar mind can join their effort.
The nonguix folks are practical. It just stinks that nothing ships with a Wifi chip that doesn't require nonguix pragmatism.
https://guix.gnu.org/manual/devel/en/html_node/Hardware-Cons...
Unfortunately, it's hard to be sure when you buy a WiFi device whether it has the right chipset. Also, most laptops come with Intel WiFi, and that requires non-free firmware.
The blob is better viewed as a part of the hardware in this case. What's most likely to happen to get rid of the blob is to just put it on the non-modifiable parts of the device. Viewed in this way, the blob is at least something you can practically inspect, unlike the firmware on the chip itself.
See also the discussion on CPU microcode:
https://lists.gnu.org/archive/html/info-gnu/2018-04/msg00002...
They all run proprietary blobs inside and out. It's ridiculous gatekeeping to say that on the kernel level it's bad, but below it I just put my head in the sand and disregard the millions of lines of closed-source code.
nix build nixpkgs#pkgsStatic.emacs
people need to understand what freedom means. sure, do inform others about the downsides of using non-free stuff... but it's very hard to help freedom by shaming and alienating people for trying to use hardware they already own.
let chromium = pkgs.chromium; in 1 + 1